現在位置: ホーム / セキュリティ ブログ / OpenStack Mitakaのセキュリティについて(2)

OpenStack Mitakaのセキュリティについて(2)

OpenStack Mitakaの新規のセキュリティを紹介しています。第二回はRoleが中心になります。

こんにちは。SIOS OSSエバンジェリスト/セキュリティ担当の面です。

数回に分けて、Mitakaで変更されたセキュリティについて、各コンポーネントごとに見ています。

今回は、Mitakaで変更されたセキュリティの中のRole関連について説明したいと思います。


RBACとImplied Roleについて

アクセス制御系のセキュリティの中でも、Role Base Access Control(RBAC)は広く使われているので、ご存じの方も多いと思います。

RBACでは、Role(役割)に出来る行為を割り当てておき、ユーザをそのRoleに所属させることで、ユーザのアクセス権を設定します。

OpenStackでも、プロジェクトやネットワークなど所々の権限の管理にRBACが利用出来るようになっています。

今回のリリースでは、Implied Roleという考えが新たに加わっています。

簡単に言ってしまうと、Roleの継承と同じようなコンセプトです。ただ、Implied Roleでは継承に比べて

  • 多数の親を持てる

  • 継承の場合には子・孫と延々と伝搬していくのに対して、設定した代のみ

のため、簡単という利点が有ります。

Implied Roleのサンプルにもあるように、例えば

Pic1

のような関係にRoleがなっている場合には、implied_role_idを使うと

Pic2

のように簡単に定義できます。


Implied Roleを試す

簡単にImplied Roleを試してみましょう。

まず最初に気をつけなくてはならないことですが、今回のMitakaではこちらにもある通り、Implied RoleのCLI/clientサポートは無いため、curl/jqを使ってAPIを叩いてあげる必要が有ります。

curlを用いたAPIの叩き方は、こちらにまとまっています。

また、こちらにAPIの表もあるので、これらを参考にしてテストを行います。

前提としてですが、OpenStackのサイトにあるように、ubuntuを用いてmitakaのKeystoneを作成してテストを行っています。

1. openstackrcファイルを作成する

openstack client(ubuntuの場合には、openstackコマンド)、curlやjdを使う際にパスワードなどの環境変数をシェルに設定するために、こちらに従ってopenstackrcファイルを作成します。

今回の場合には

export OS_PROJECT_DOMAIN_NAME=default
export OS_USER_DOMAIN_NAME=default
export OS_PROJECT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=[パスワード]
export OS_AUTH_URL=http://controller:35357/v3
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2

のようにし、ホームディレクトリに置いておきます。以降、openstackの環境に接続する際には、忘れずに

openstack@controller:~$ . ~/openstackrc

として、環境変数を読み込んで下さい。ユーザの.bashrcなどに仕込んでおいても良いかもしれません。

2. テスト用にUser、Role、プロジェクトを作成する

openstackコマンドを用いて、下のようなUser、Role、プロジェクトを作成します。

今回はテストのため、ドメインは全て「default」を使っています。

IDの所は、実際にはランダムに割り当てられるはずです。

User: openstack user create [User名] --domain [ドメイン名]で作成
+----------------------------------+-------+
| ID                               | Name  |
+----------------------------------+-------+
| bed186d74c6a40eab3c49698d3c9eb2c | Ken   |
| d38bcb7c5c364a88837bc6421c904ec0 | demo  |
| fe815c97274d43edaf5a8d3869ad368b | admin |
+----------------------------------+-------+

Role: openstack role create [Role名]で作成
+----------------------------------+-----------------+
| ID                               | Name            |
+----------------------------------+-----------------+
| 03880bc85e67484d8f3a57b8ff9e3e7e | admin           |
| 71f24a5042c74bdc954f81953dd6dba4 | prior_test123   |
| 8e22d36d34f94bd9affd00518942048d | user            |
| e2651277dfd34043b071fbccc1b07b98 | implied_test456 |
+----------------------------------+-----------------+

Project: openstack project create [Project名] --domain [ドメイン名]で作成
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 65e130c17cc549c9992f491c225061bd | service |
| 766ffe6c7f0f4e3f8dd8dd7ce309c564 | demo    |
| fdc2a8edfe2f4c179d727108f4a03ddc | admin   |
+----------------------------------+---------+

3. curlでAPIを叩いてprior Roleとimplied Roleを関連付ける

prior Role(prior_test123)とimplied Role(implied_test456)を関連付けます。ここの所は、mitakaでのopenstackクライアントは対応していないため、curlを用いてAPIを叩いて設定してあげる必要が有ります。

まず、identityを取得するため、下記のようなJSONファイル(token-request.json)を作成します。

{
    "auth": {
        "identity": {
            "methods": [
                "password"
            ],
            "password": {
                "user": {
                    "domain": {
                        "name": "default"
                    },
                    "name": "admin",
                    "password": "[パスワード]"
                }
            }
        },
        "scope": {
            "project": {
                "domain": {
                    "name": "default"
                },
                "name": "admin"
            }
        }
    }
}

このtoken-request.jsonを用いて、curlでTOKENを取得し、APIを叩きます。下記のスクリプトを用意します。

#!/bin/sh 
. ~/adminrc

export OS_TOKEN=`curl -si -d @token-request.json -H "Content-type: application/json" $OS_AUTH_URL/auth/tokens | awk '/X-Subject-Token/ {print $2}'`

curl -s -X PUT -H "X-Auth-Token:$OS_TOKEN" $OS_AUTH_URL/roles/71f24a5042c74bdc954f81953dd6dba4/implies/e2651277dfd34043b071fbccc1b07b98 |python -mjson.tool

最初にcurlでOS_TOKENを取得しています。下の行は、先に出したこちらのページの「identity:create_implied_role」のマッピングを参考に、roles/{prior_test123のID}/implies/{implied_test456のID}としてprior_test123とimplied_test456を関係づけて設定しています。

4. テスト用ユーザ(Ken)をprior_test123 Roleに所属させる

openstackコマンドを用いて、テスト用ユーザ(Ken: bed186d74c6a40eab3c49698d3c9eb2c)をadmin プロジェクト(fdc2a8edfe2f4c179d727108f4a03ddc)で、prior_test123 Roleに参加させます。下記のようになります。

openstack@controller:~$ openstack role add --user bed186d74c6a40eab3c49698d3c9eb2c --project fdc2a8edfe2f4c179d727108f4a03ddc prior_test123

念の為、Kenがproject: adminでどんなRoleに(明示的に)所属しているかをopenstackコマンドで確認します。

openstack@controller:~$ openstack role list --user Ken --project admin
+----------------------------------+---------------+---------+------+
| ID                               | Name          | Project | User |
+----------------------------------+---------------+---------+------+
| 71f24a5042c74bdc954f81953dd6dba4 | prior_test123 | admin   | Ken  |
+----------------------------------+---------------+---------+------+
openstack@controller:~$ 

となり、prior_test123にKenが明示的に所属しているのがわかります。

5. Kenのがimplied Roleに引き継がれて所属しているかを確認する

3.で行った設定により、prior Role(prior_test123)に所属しているものは、implied Role(implied_role456)にも引き継がれているはずです。

これを確認するため、3.の時と同じく、ユーザKenのJSONファイル(token-request-ken.json)を下記のように用意します(ほとんど同じで、ユーザとパスワードのみ異なります)。

{
    "auth": {
        "identity": {
            "methods": [
                "password"
            ],
            "password": {
                "user": {
                    "domain": {
                        "name": "default"
                    },
                    "name": "ken",
                    "password": "[パスワード]"
                }
            }
        },
        "scope": {
            "project": {
                "domain": {
                    "name": "default"
                },
                "name": "admin"
            }
        }
    }
}

このJSONファイルを用いて、下記のようにcurlで直接APIを叩いて、Kenが最終的に所属しているroleを出力します。

curl  -d @token-request-ken.json -H "Content-type: application/json" $OS_AUTH_URL/auth/tokens | jq '.token | {roles}'

出力は、下記のようになり、Kenが二つのRole(prior_test123とimplied_test456)に所属していることがわかります。

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1708  100  1166  100   542  10288   4782 --:--:-- --:--:-- --:--:-- 10318
{
  "roles": [
    {
      "id": "e2651277dfd34043b071fbccc1b07b98",
      "name": "implied_test456"
    },
    {
      "id": "71f24a5042c74bdc954f81953dd6dba4",
      "name": "prior_test123"
    }
  ]
}

このように、implied roleを用いてRoleの継承などが簡単に設定できます。mitakaのバージョンではCLIが未サポートのためAPIを直接叩くのでわかりにくいですが、次のバージョンからはCLIでもサポートされ、より設定が簡単になると思われます。


Domain-Specific-Roleについて

Domain-Specific-Roleは、Implied Roleの機能を使って、WindowsのADドメインのように簡単にRoleを管理させようと言うものです。

こちらにコンセプトと詳しい内容が載っていますが

  • このロールは完全にプライベートであり、ドメインnamespace内のみに存在する。

  • その他のドメインは、このロールによる影響は受けない

  • この「ドメイン固有のロール」はトークンの中に現れない

というものになります。このDomain-Specific-Roleも、implied roleのmitakaへのインプリメントに依存していますので、完全な状態を見るにはmitakaの次のリリースを待つ必要が有ります(今回は詳細の紹介は割愛します)。


まとめ

今回はMitakaでのセキュリティ上の改善の中から、特にKeystoneの中のRole部分について説明しました。

次回はKeystoneでのセキュリティ上の改善点の残りの部分を説明します。

また、SIOSではOpenStackのPoC支援のサポートメニュー提供を開始しています。

OpenStackに関しての導入を検討されている方は、是非こちらもご活用頂ければと思います。


[参考]

openstack mitaka

OpenStack Releases; Mitaka


[セミナー告知]

7/22にノベル株式会社様と共催で「クラウド・OSSセキュリティセミナー」と題して、OpenStack基盤自体のセキュリティに関して、デモを交えたセミナーを行います。

https://sios.secure.force.com/webform/SeminarDetail?id=70110000000sotpAAAがプログラム内容と申し込みの詳細になりますので、是非お申し込み下さい。

OSSよろず相談室

サイオスOSSよろず相談室(2)

問い合わせボタン

最新の記事
linux kernelの脆弱性( CVE-2017-7277 ) 2017年03月29日
ntpに複数の脆弱性(CVE-2017-6451, CVE-2017-6452, CVE-2017-6455, CVE-2017-6458, CVE-2017-6459, CVE-2017-6460, CVE-2017-6462, CVE-2017-6463, CVE-2017-6464 ) 2017年03月28日
linux kernelの脆弱性( CVE-2017-7273 ) 2017年03月28日
AppArmorの脆弱性( CVE-2017-6507 ) 2017年03月26日
linux kernelの脆弱性( CVE-2017-7261 ) 2017年03月25日
Sambaに共有以外のファイルにアクセスされる脆弱性(CVE-2017-2619) 2017年03月24日
Subscription-managerの脆弱性( CVE-2017-2663 ) 2017年03月22日
binutilsに複数の脆弱性( CVE-2017-6965, CVE-2017-6966, CVE-2017-6969, CVE-2017-7209 , CVE-2017-7210 , CVE-2017-7223, CVE-2017-7224, CVE-2017-7225, CVE-2017-7226, CVE-2017-7227 ) 2017年03月22日
linux kernelの脆弱性( CVE-2017-7187 ) 2017年03月21日
linux kernelの脆弱性( CVE-2017-6353 , CVE-2017-5986 ) 2017年03月21日
Ubuntu 16.10のkernelの脆弱性( CVE-2017-7184 ) 2017年03月20日
pcreの脆弱性( CVE-2017-7186 ) 2017年03月20日
binutilsの脆弱性( CVE-2017-6965 , CVE-2017-6966 , CVE-2017-6969 ) 2017年03月19日
MySQL(MariaDB) 5.5/5.6のmysql clientの脆弱性( Riddle : CVE-2017-3305 ) 2017年03月18日
linux kernelの脆弱性( CVE-2017-6951 ) 2017年03月17日
Apache Struts2の脆弱性 ( CVE-2017-5638 ) 2017年03月15日
linux kernelの脆弱性( CVE-2017-6874 ) 2017年03月15日
tomcatに情報漏えいの脆弱性( CVE-2016-8747 ) 2017年03月14日
QEMUの脆弱性( CVE-2016-9603 ) (Xen: XSA-211) 2017年03月14日
lxcの脆弱性(CVE-2017-5985) 2017年03月10日
wgetの脆弱性(CVE-2017-6508) 2017年03月08日
linux kernelに特権昇格の脆弱性( CVE-2017-2636 ) 2017年03月08日
( PoC ) linux kernel特権昇格脆弱性( CVE-2017-6074 ) の暫定回避策の確認 2017年03月06日
linux kernelの脆弱性( CVE-2016-9083 , CVE-2016-9084 ) 2017年03月03日
linux kernelに複数の脆弱性( CVE-2017-6345 , CVE-2017-6346 , CVE-2017-6347 , CVE-2017-6348 ) 2017年03月01日
Katello/Foremanによる運用管理 (Part4) 2017年02月28日
util-linux / coreutils の脆弱性(CVE-2017-2616) 2017年02月24日
linux kernelの脆弱性( CVE-2017-6214 ) 2017年02月24日
linux kernelに特権昇格の脆弱性( CVE-2017-6074 ) 2017年02月23日
curlの脆弱性 ( CVE-2017-2629 ) 2017年02月22日
QEMUの脆弱性( CVE-2017-2620 ) (Xen: XSA-209) 2017年02月22日
Tomcatの脆弱性 ( CVE-2017-6056 ) 2017年02月21日
Katello/Foremanによる運用管理 (Part3) 2017年02月21日
OpenSSLの脆弱性 ( CVE-2017-3733 ) 2017年02月16日
linux kernelの脆弱性( CVE-2017-6001 , (was CVE-2016-6786) ) 2017年02月16日
QEMUの脆弱性( CVE-2017-2630 ) 2017年02月15日
glibcの脆弱性(CVE-2015-8982, CVE-2015-8983, CVE-2015-8984) 2017年02月15日
vimの脆弱性 ( CVE-2017-5953 ) 2017年02月14日
Oracle Javaの脆弱性(Oracle Critical Patch Update Advisory - January 2017) 2017年02月14日
libxml2の脆弱性(CVE-2017-5969) 2017年02月13日
「linux kernel-4.9」でのLSMモジュールについて 2017年02月13日
linux kernelの脆弱性( CVE-2017-5970 ) 2017年02月13日
linux kernelの脆弱性( CVE-2016-8636 ) 2017年02月12日
bind 9 に設定依存の脆弱性 ( CVE-2017-3135 ) 2017年02月09日
bashの自動補完機能の脆弱性( CVE-2017-5932 ) 2017年02月08日
spiceの脆弱性( CVE-2016-9577 , CVE-2016-9578 ) 2017年02月08日
QEMUの脆弱性( CVE-2017-5898 ) 2017年02月08日
linux kernelの脆弱性( CVE-2017-5897 ) 2017年02月08日
linux kernelの脆弱性( CVE-2016-10208 ) 2017年02月06日
ntfs-3gの脆弱性(CVE-2017-0358) 2017年02月02日
QEMUの脆弱性( CVE-2017-2615 ) 2017年02月02日
tcpdumpに複数の脆弱性(CVE-2016-7922 等) 2017年01月30日
libgdに複数の脆弱性情報 (CVE-2016-9317, CVE-2016-6912, CVE-2016-10167, CVE-2016-10168, CVE-2016-10169) 2017年01月29日
OpenSSLに複数の脆弱性 ( CVE-2017-3730 , CVE-2017-3731 , CVE-2017-3732 ) 2017年01月27日
RunCに関しての脆弱性( CVE-2016-9962 )のPoCとSELinuxによるリスクの軽減 2017年01月26日
systemdの重要な脆弱性( CVE-2016-10156 ) 2017年01月25日
linux kernelの複数の脆弱性( CVE-2016-10153, CVE-2016-10154, CVE-2017-5547, CVE-2017-5548, CVE-2017-5549, CVE-2017-5550, CVE-2017-5551) 2017年01月25日
Katello/Foremanによる運用管理 (Part2) 2017年01月24日
linux kernel(KVMを有効にしている場合)で複数の脆弱性( CVE-2016-10150, CVE-2017-2583 ) 2017年01月21日
OpenSCAP 1.2.13のリリース情報 2017年01月16日
最新の記事 - もっと...