OpenStack Mitakaのセキュリティについて(2)
こんにちは。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のサンプルにもあるように、例えば
のような関係にRoleがなっている場合には、implied_role_idを使うと
のように簡単に定義できます。
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に関しての導入を検討されている方は、是非こちらもご活用頂ければと思います。
7/22にノベル株式会社様と共催で「クラウド・OSSセキュリティセミナー」と題して、OpenStack基盤自体のセキュリティに関して、デモを交えたセミナーを行います。
https://sios.secure.force.com/webform/SeminarDetail?id=70110000000sotpAAAがプログラム内容と申し込みの詳細になりますので、是非お申し込み下さい。