OpenStackドメインは、プロジェクトまたはテナント（Grizzlyで呼び出されたため）を独立したグループに結合する方法です。 さらに、特定のドメインへのアクセスを制限できます。 たとえば、おそらく覚えているように、ドメインを使用しなかった場合、1つのプロジェクトで管理者の役割を割り当てられたユーザーはクラスター全体の管理者であり、あらゆる操作を実行できました。 ドメインの出現により、あるドメインの管理者権限を持つユーザーに、そのドメインのみの管理者ロールを割り当てることができます。
この記事では、ドメインがプロジェクトの編成に役立つ状況について簡単に説明します。 これを理解したら、この目的で実際にドメインを使用する方法を検討します。
やる気
約1年前、企業クライアントの1つがOpenStackドメインと非常によく似た機能を要求したときに初めてドメインに遭遇しました。 これはグリズリーサイクルの一部でした。 私たちはそれについて読んで言った：「ヨーホホ！ ドメイン機能を使用できます！」 そのとき、それはちょうど導入されました。
しかし、OpenStackは... OpenStackであり、この機能は必要なすべてのコンポーネントでサポートされていませんでした。 そのため、Keystoneにパッチを作成して、要求された使用シナリオを実装し、後でこれに戻ることにしました。
6か月後、ハバナのリリースが発表されました。 ドメインの機能は企業セグメントにとって非常に有用であるため、バニラハバナリリースを使用してコンセプトの正確性の証明を取得することにしました。
次のユースケースをカバーしたいと思いました。
1. IaaS管理者として、テナント（現在はプロジェクト）を集約するためのドメインを作成できる必要があります。
2. IaaS管理者として、ドメイン管理者としてユーザーを追加できる必要があります。
3.ドメイン管理者として、次のことができるはずです。
•このドメイン内でプロジェクトを作成、削除、移動、更新、削除します。 プロジェクトのリストには、このドメインのプロジェクトのみを含める必要があります。
•プロジェクトの役割に関連して、ユーザーに対してCRUD操作を実行します。
4.ユーザー名/パスワードのソースとしてLDAPを使用する必要があります。
5.必ずREST APIのみを使用してください。 UIもCLIも必要ありません。
今回はやった。 問題はなかったとは言いませんが、プロジェクトは少なくともHavanaリリースのドメインを適用できることを示しました。
最初に、注意、行進！
Devstackのstable / havanaブランチを使用してドメインをテストしました。 localrcファイルには、パスワードを提供するためのパラメーターのみが含まれています。
調査の過程で、CLIがドメインを使用する準備が部分的にしかできていないことがわかりました。 それは平均的なユーザーに完全な機能を提供しますが、管理のためにすべてを提供するわけではありません（ この問題の説明とその解決のための状況はここにあります ）
ドメインの機能を使用するには、次のことを行う必要があります。
1.マーカーの形式をUUIDに変更します（ファイルkeystone.conf、セクション[署名]、token_format = UUID）。 GlanceにはPKIトークン（少なくともv3トークン）に問題があり、認証されると、デフォルトのPKIを使用するときに「body is too large」エラーが生成されます（ドメインを使用するときだけでなく、問題が発生します） 。
2. keystoneに正しいpolicy.jsonファイルを適用します。 ドメインの検証は、デフォルトのポリシーファイルではサポートされていません。 gitの keystoneに付属するファイルを再利用し、 変更を加えました 。
3. [auth_version = v3.0]を[filter：authtoken]セクションに追加して、GlanceのNova、Glance-api、paste.registry構成ファイルの設定を変更し、V3.0認証を使用できるようにします。 テスト環境では、NovaとGlanceのみを使用してVMを起動しました。 他のサービスを使用する場合、対応する構成ファイルを変更することを忘れないでください。 これが行われない場合、NovaおよびGlanceクライアントはV2トークンをチェックし、「V2.0ではデフォルトドメインのみが許可されます」（「V2.0ではデフォルトドメインのみ使用可能」）というエラーを出します。
4.アイデンティティサービスがv2.0ではなくv3を指すように、Keystoneエンドポイントを更新します。
5.設定が変更されたサービスを再起動します。
クライアントのリクエストでは、RESTインターフェースのみを使用し、CLI / PythonAPI / UIクライアントは使用しなかったことに注意してください。
ドメインを管理する方法
ドメインの探索に約1週間を費やしてきたので、それらがどのように機能するかを理解するには2つの重要なポイントがあると言えます。
1.マーカー、特にトークンスコープの作成方法。
2.政治家の発足方法。
この記事では、curlコマンドを使用してすべての例を示します。 これには2つの理由があります。 まず、このドキュメントを作成するとき、CLIはコマンドラインからのドメイン関連パラメーターの設定をサポートしていませんでした。 第二に、そしてより重要なことには、CLIは、それがどのように機能するかを理解するために不可欠な詳細の一部を明らかにしません。
マーカー作成
まず、マーカーを作成する必要がありますが、これは非常に簡単です。 これは、次のクエリを使用して行われます。
curl -si -X POST -H「Content-Type：application / json」-d '{"auth"：{"scope"：{"domain"：{"id"： "XXXXX"}}、 "identity"： {「パスワード」：{「ユーザー」：{「ドメイン」：{「名前」：「デフォルト」}、「パスワード」：「qwerty」、「id」：「YYYYYY」}}、「メソッド」：[「パスワード"]}}}" 127.0.0.1：5000 / v3 / auth /トークン| awk '/ X-Subject-Token / {print $ 2}' | tr -d '\ r'
ここでは、本体として渡されるjsonファイルの重要な部分、つまりスコープを確認できます。 ドメインは、ドメインまたはプロジェクトのいずれかです。 マーカー領域はポリシーの実行に関係しているため、これを理解して覚えておくことが重要です。 興味がある場合は、関数keystone / auth / controllers.py：AuthInfo._validate_and_normalize_scope_dataを見て、オブジェクトを作成するために使用されたコードを見つけ、それを使用してポリシー資格情報を生成できます。
起動ポリシー
ポリシーの実行はより複雑です。 これが主な使用例です。 幸いなことに、これがどのように発生するかを明確に理解すると、ほとんどのドメイン操作を実行できます。 ポリシーを開始するときに、資格情報、ポリシー、ターゲットの3つの新しいキーワードが使用されます。 それでは、それぞれの作成と使用方法を見てみましょう。
クレデンシャル
資格情報オブジェクトは、マーカーに基づいて作成されたマーカーであり、受信したマーカーの領域と、ユーザーに割り当てられたロールが含まれます。
方針
ポリシーは、OR / ANDロジックに従って結合されたルールのセットです。 将来のリリースでは、より読みやすくなるはずですが、現時点では現在使用されている形式を使用します。 以下は、上記の例としてのポリシーの一部です。
「Admin_required」：[[「ロール：admin」]]、
「所有者」：[["user_id：％（user_id）s"]、["user_id：％（target.entity.user_id）s"]]、
「ID：get_project」：[[「rule：admin_required」、
「Domain_id：％（target.project.domain_id）s」]]、
「ID：list_projects」：[[「rule：admin_required」、「domain_id：％（domain_id）s」]]]、
「ID：list_user_projects」：[[「ルール：所有者」]、[「ルール：admin_required」、
「Domain_id：％（domain_id）s」]]、
すべてを角括弧（[]）で囲む必要があります。
ルールの最小フラグメント（「アトミック」ルールと呼ぶことができます）は、区切り文字としてコロン（ '：'）を使用した文字列です。 可能性があります：
1.別のルールへのリンク。 この場合、左側が「ルール」で、右側がルールの名前です。
2.検証ロジックの定義。 この場合、左側は資格情報オブジェクトにあるキーを定義し、右側は「ターゲット」にあるキーを定義します。 定数にすることもできます。 これは、credentials_object [left_side] == right_side％target_objectとして表現できます。
コンマ（、）を使用して、いくつかのアトミックルールを組み合わせることができます。 つまり、これらのルールはANDロジックに基づいて結合されます（例：[“ rule：admin_required”、“ domain_id：％（domain_id）s”]）。 これを「およびルール」と呼びます。
[]で囲まれた2組のルールがある場合、それらはORロジックに基づいて結合されます。 たとえば、[["rule：owner"]、["rule：admin_required"]]は、所有者のルールまたは管理者が必要とするルールが実行された場合にルールが実行されることを意味します。
ルールが別のルールを使用する場合、括弧で囲まれたルールは同じ方法で説明する必要があります。
要約すると、例：「” identity：list_user_projects”：[["rule：owner '']、[“ rule：admin_required”、“ domain_id：％（domain_id）s]]]」は、「ユーザープロジェクトのリストは、名前が「owner」の場合、または管理者が必要とするルールが実行され、かつトークン領域のdomain_idがターゲットのドメインIDに等しい場合。 次に、目標に焦点を当てます。
対象
ターゲットオブジェクトは、以下に基づいて作成された辞書でもあります。
•クエリ（要求）からのクエリ文字列。
•起動されたオブジェクト。
例：
•プロジェクトに関する情報を取得しようとしている場合、目標はこのプロジェクトです
•特定のロールを持つユーザーをプロジェクトに割り当てようとする場合、目標はロール+プロジェクト+ユーザーです。
•すべてのプロジェクトを一覧表示しようとすると、目標値は空になります（最初は、顧客から要求された操作の一部がHavanaリリースで利用できないと思ったため、動揺しました。しかし、幸運なことに、私は間違っていました）。
•特定の値によるフィルター（domains_idなど）を使用してすべてのプロジェクトをリストしようとすると、目標にはすべてのフィルターが含まれます（これは私にとって驚きでしたが、非常に有用であることがわかりました）。
リクエストの例：
curl -sX GET -H“ X-Auth-Token：$ OS_MYTOKEN” 127.0.0.1：5000 / v3 / projects？domain_id = $ OS_DOMAIN_ID
このリクエストでは、domain_idのみがターゲットに含まれます。 policy.jsonファイルに含まれるルールは、「identity：list_projects」：[[「rule：admin_required」、「domain_id：％（domain_id）s」]]のようになります。
このすべてを知っていると、policy.jsonファイルに変更を加えることでアクセスを簡単に制御できます。
さらに、デバッグメッセージをkeystone / policy / backends / rules.pyに書き込むことができます。より徹底的な分析のために、資格情報、ルール、および目標をログに記録します。 この方法は、いくつかのユースケースで何が起こるかを理解するのに役立ちました。
クラウド管理者
既存のpolicy.jsonファイルによると、「cloud_admin」ルールの意味は明確ではありませんでした。
「Cloud_admin」：「ルール：admin_requiredおよびdomain_id：admin_domain_id」、
「ID：get_domain」：「ルール：cloud_admin」、
いくつかの調査を行った結果、これはサービストークンを使用せずに「スーパー管理者」を定義するための非常に洗練された回避策であることがわかりました。 「スーパードメイン」であるドメインを作成し、対応するIDをルールのadmin_domain_id値として指定するだけです。 たとえば、devstackで「default」を使用し、デフォルトドメインを「super」管理者として指定できます。
Keystoneの主要幹部による議論によると、クラウド管理者の概念は一時的なソリューションであり、サービス管理者の概念に置き換えられます。
Horizonサポート
ブループリントによると、Horizonは複数のドメインもサポートできます。 これを行うには、settings.pyまたはlocal_setting（ラボでテスト済み）にわずかな変更を加えるだけです。
OPENSTACK_API_VERSIONS = {
「アイデンティティ」：3
}
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
#OPENSTACK_KEYSTONE_URL =“ http：//％s：5000 / v2.0″％OPENSTACK_HOST
OPENSTACK_KEYSTONE_URL =“ http：//％s：5000 / v3″％OPENSTACK_HOST
これらの変更を行った後、ログインの段階でドメイン名を示す追加の入力フィールドを受け取ります。 残念ながら、V3ポリシー（ link ）をkeystoneに適用する場合、管理者のアクション（ドメイン管理や予定など）はHorizonで利用できません。ただし、この結果、一般ユーザーは少なくともCURLコマンドを送信する代わりにUIを使用できます。
コマンドラインインターフェース（CLI）
2014年1月中旬に、CLIにドメインサポートが追加され、次の追加オプションセットがサポートされるようになりました。
–Os-domain-name <認証ドメイン名>
要求されたドメインレベルの承認領域のドメイン名（環境：OS_DOMAIN_NAME）。
–Os-domain-id <auth-domain-id>
要求されたドメインレベルの承認領域のドメインID（環境：OS_DOMAIN_ID）。
–Os-user-domain-name <認証ユーザードメイン名>
ユーザードメイン名（環境：OS_USER_DOMAIN_NAME）。
–Os-user-domain-id <auth-user-domain-id>
ユーザードメインID（環境：OS_USER_DOMAIN_ID）。
–Os-project-domain-name <auth-project-domain-name>
プロジェクトのドメイン名。これは、要求されたドメインレベルの承認領域です（環境：OS_PROJECT_DOMAIN_NAME）。
–Os-project-domain-id <auth-project-domain-id>
プロジェクトドメインID。これは、要求されたドメインレベルの承認領域です（環境：OS_PROJECT_DOMAIN_ID）。
これらのパラメーターを使用して、マーカー領域、プロジェクトドメイン、およびユーザードメインを設定できます。
すべてをまとめる
上記のすべての変更を適用すると、必要なすべての機能を実行できます。 以下はcurlコマンドのリストです。 このテスト中に機能が動作するためには、RESTリクエストのみが実行されていることを確認する必要があることを思い出してください。
前提条件：
JSON応答の便利な分析のために、jqツールを使用しました。
sudo apt-get install jq
ユーザーを作成しました（LDAPから）：user0、demo
例：
テストは次のとおりです。
#export開始変数。
export OS_AUTH_URL = http：//127.0.0.1：5000 / v3
エクスポートOS_SERVICE_TOKEN = openstack
＃ドメインのリスト
curl -sX GET -H“ X-Auth-Token：$ OS_SERVICE_TOKEN” 127.0.0.1：35357 / v3 / domains | jq '.domains'
＃または
openstack –os-identity-api-version 3 –os-url 127.0.0.1：35357 / v3 –os-token openstackドメインリスト
＃ドメインを作成
curl -sX POST -H「X-Auth-Token：$ OS_SERVICE_TOKEN」-H「Content-Type：application / json」-d '{"domain"：{"enabled"：true、 "name"： "dom0″} } ' 127.0.0.1：35357 / v3 /ドメイン| jq '。'
#list show domain0
curl -s -X GET -H“ X-Auth-Token：$ OS_SERVICE_TOKEN” 127.0.0.1：35357 / v3 / domains？name = dom0 | jq '.domains'
＃ユーザーをドメイン管理者として割り当てる
＃ユーザーIDを取得
curl -sX GET -H“ X-Auth-Token：$ OS_SERVICE_TOKEN” 127.0.0.1：35357 / v3 / users？名前= user0 | jq '.users'
export OS_USER_ID = curl -sX GET -H "X-Auth-Token：$ OS_SERVICE_TOKEN" 127.0.0.1：35357 / v3 / users？name = user0 | jq '.users []。id' | tr -d '"'
curl -sX GET -H“ X-Auth-Token：$ OS_SERVICE_TOKEN” 127.0.0.1：35357 / v3 / domains？name = dom0 | jq '.domains'
export OS_DOMAIN_ID = curl -sX GET -H "X-Auth-Token：$ OS_SERVICE_TOKEN" 127.0.0.1：35357 / v3 / domains？name = dom0 | jq '.domains []。id' | tr -d '"'
curl -sX GET -H“ X-Auth-Token：$ OS_SERVICE_TOKEN” 127.0.0.1：35357 / v3 / roles？name = admin | jq '.roles'
curl -sX PUT -H“ X-Auth-Token：$ OS_SERVICE_TOKEN” 127.0.0.1：35357 / v3 / domains / $ OS_DOMAIN_ID / users / $ OS_USER_ID / roles / bc485df1732140928ad44804a1c9b546
curl -sX GET -H“ X-Auth-Token：$ OS_SERVICE_TOKEN” 127.0.0.1：35357 / v3 / domains / $ OS_DOMAIN_ID / users / $ OS_USER_ID / roles / | jq '.roles'
＃ドメイン管理者として認証する
export OS_MYTOKEN = curl -si -X POST -H "Content-Type：application / json" -d "{\" auth \ "：{\" scope \ "：{\" domain \ "：{\" id \ " ：\ "$ OS_DOMAIN_ID \"}}、\ "アイデンティティ\"：{\ "パスワード\"：{\ "ユーザー\"：{\ "ドメイン\"：{\ "名前\"：\ "デフォルト\"} 、\ "パスワード\"：\ "qwerty \"、\ "id \"：\ "$ OS_USER_ID \"}}、\ "methods \"：[\ "password \"]}}} " 127.0.0.1：5000 / v3 / auth /トークン| awk '/ X-Subject-Token / {print $ 2}' | tr -d '\ r'
＃プロジェクトを作成
curl -sX POST -H“ X-Auth-Token：$ OS_MYTOKEN” -H“ Content-Type：application / json” -d“ {\” project \”：{\” name \”：\” dom0p0 \”、 \”有効\”：true、\” domain_id \”：\” $ OS_DOMAIN_ID \”、\” description \”：\” \”}}” 127.0.0.1：5000 / v3 / projects | jq '。'
curl -sX GET -H“ X-Auth-Token：$ OS_MYTOKEN” 127.0.0.1：5000 / v3 / projects？domain_id = $ OS_DOMAIN_ID \＆name = dom0p0 | jq '.projects'
export OS_PROJECT_ID = curl -sX GET -H "X-Auth-Token：$ OS_MYTOKEN" 127.0.0.1：5000 / v3 / projects？domain_id = $ OS_DOMAIN_ID \＆name = dom0p0 | jq '.projects []。id' | tr -d '"'
＃ユーザーをプロジェクトに追加
curl -sX GET -H“ X-Auth-Token：$ OS_MYTOKEN” 127.0.0.1：35357 / v3 / users？名前=デモ| jq '.users'
export OS_DEMOUSER_ID = curl -sX GET -H "X-Auth-Token：$ OS_MYTOKEN" 127.0.0.1：35357 / v3 / users？name = demo | jq '.users []。id' | tr -d '"'
curl -sX GET -H“ X-Auth-Token：$ OS_MYTOKEN” 127.0.0.1：35357 / v3 / roles？名前=メンバー| jq '.roles'
curl -X PUT -H“ X-Auth-Token：$ OS_MYTOKEN” 127.0.0.1：5000 / v3 / projects / $ OS_PROJECT_ID / users / $ OS_DEMOUSER_ID / roles / c861b57d824d4619a739823d863064b6
curl -X GET -H“ X-Auth-Token：$ OS_MYTOKEN” 127.0.0.1：5000 / v3 / projects / $ OS_PROJECT_ID / users / $ OS_DEMOUSER_ID / roles / | jq '.roles'
＃ユーザーとして認証する
export OS_DEMOTOKEN_ID = curl -si -X POST -H "Content-Type：application / json" -d "{\" auth \ "：{\" scope \ "：{\" project \ "：{\" id \ " ：\ "$ OS_PROJECT_ID \"、\ "domain \"：{\ "id \"：\ "$ OS_DOMAIN_ID \"}}}、\ "identity \"：{\ "password \"：{\ "user \" ：{\ "Domain \"：{\ "name \"：\ "default \"}、\ "password \"：\ "openstack \"、\ "id \"：\ "$ OS_DEMOUSER_ID \"}}、\ "メソッド\"：[\ "パスワード\"]}}} " 127.0.0.1：5000 / v3 / auth / tokens | awk '/ X-Subject-Token / {print $ 2}' | tr -d '\ r'
#VMを実行
curl -si -X POST -H“ X-Auth-Token：$ OS_DEMOTOKEN_ID” -H“ Content-Type：application / json” -d '{“サーバー”：{“ flavorRef”：“ 1″、“ name”： 「Ksn」、「imageRef」：「c0843d76-0cc8-4a19-a9e3-169afd3aace2 ''}} ' 127.0.0.1：8774 / v2 / $ OS_PROJECT_ID / servers
未解決の質問
一般に、これは成功と呼ぶことができますが、それでも未解決の問題がいくつかあります。
1. V3ポリシーをkeystoneに適用するときに、Horizonが管理者の操作を管理できるかどうかは不明です。
2.ユーザードメインを別のドメインから別のプロジェクトに割り当てた場合、ドメインを削除することはできません。 問題 。
結論
まとめると、Horizonのドメインの機能を使用するには、まずKeystone APIバージョンV3を使用していることと、認証スキームをUUIDに変更したことを確認する必要があります。 次に、トークンを作成してから、適切なポリシーを作成して実行する必要があります。 これを実行した後、リストのコマンドを使用してドメインを作成および使用できます。また、Horizonまたは新しいCLIパラメーターを使用できます。
英語のオリジナル記事。