OpenStack Dashboard はユーザーを管理するグラフィカルインターフェースを提供します。このセクションは Dashboard を用いたユーザー管理を説明します。
コマンドラインクライアントから プロジェクト、ユーザー、ロールを管理する こともできます。
さらに、多くのサイトは個別の要求を満たすために独自ツールを作成し、サイト固有のポリシーを適用し、パッケージツールでは実現できないレベルのセルフサービスをユーザーに提供しています。
ユーザーを作成するには、以下の情報が必要です。
ユーザー名と電子メールアドレスは見たとおりです。あなたのサイトは従うべき独自ルールがあるかもしれません。主プロジェクトは単にユーザーが割り当てられる最初のプロジェクトです。ユーザーを作成する前に存在している必要があります。役割は多くの場合ずっと 「メンバー」 のままになります。標準の状態で、OpenStack は次の 2 つの役割が定義されています。
他の役割を定義できますが、一般的にはそうしません。
一度この情報を収集すると、ダッシュボードでのユーザーの作成は、これまでに見てきた他の Web フォームと同じです。 ユーザー管理 ナビゲーションバーの ユーザー リンクにあります。そして、右上にある ユーザーの作成 ボタンをクリックします。
ユーザー情報の変更は、この ユーザー ページから実行することもできます。かなり多くのユーザーがいるならば、このページにはたくさんのユーザーが表示されることでしょう。ページの上部にある フィルター 検索ボックスを使うと、表示されるユーザーの一覧を絞り込むことができます。変更しようとしているユーザーの行末にあるアクションドロップダウンメニューの 編集 を選択することにより、ユーザー作成ダイアログと非常に似ているフォームを表示できます。
多くのサイトは一つのプロジェクトのみに割り当てられているユーザーで実行しています。これは、管理者にとってもユーザーにとっても、より保守的で分かりやすい選択です。管理の面では、ユーザーからインスタンスやクォータに関する問題の報告があった場合、どのプロジェクトに関するものかが明確です。ユーザーが一つのプロジェクトのみに所属している場合、ユーザーがどのプロジェクトで操作しているのかを気にする必要がありません。ただし、既定の設定では、どのユーザーも同じプロジェクトにいる他のユーザーのリソースに影響を与えることができることに注意してください。あなたの組織にとって意味があるならば、ユーザーを複数のプロジェクトに割り当てることも可能です。
既存のユーザーを追加のプロジェクトに割り当てる、または古いプロジェクトから削除することは、以下のスクリーンショットにあるとおり、ダッシュボードの プロジェクト ページから、アクション 列のユーザーの変更を選択することにより実行できます。
このビューから、数多くの有用な操作、いくつかの危険な操作を実行できます。
すべてのユーザー (All Users) という見出しが付けられた、このフォームの最初の列に、このプロジェクトにまだ割り当てられていない、クラウドのすべてのユーザーが一覧表示されます。2 列目には、すべての割り当て済みユーザーが一覧表示されます。これらの一覧は非常に長い可能性があります。しかし、それぞれの列の上部にあるフィルターフィールドに、探しているユーザー名の部分文字列を入力することにより、表示を絞り込むことができます。
ここから、プロジェクトにユーザーを追加するには + アイコンをクリックします。削除するには - をクリックします。
危険な点としては、メンバーの役割を変更する機能があることです。これは プロジェクトメンバー 一覧のユーザー名の後ろにあるドロップダウンリストです。事実上すべての場合で、この値は メンバー に設定されています。この例では意図的に、この値が admin
になっている管理ユーザーを示しています。
警告
管理者はプロジェクトごとではなく、グローバルです。そのため、ユーザーに admin
ロールを与えることにより、クラウド全体にわたるユーザー管理権限を与えることになります。
一般的な使用法は、一つのプロジェクトだけに管理ユーザーを所属させることです。慣例により、」admin」 プロジェクトがクラウド環境のセットアップ中に標準で作成されます。管理ユーザーもクラウドを使用してインスタンスの起動、管理を行う場合には、管理アクセスと一般アクセス用に別々のユーザーアカウントを使用し、それらのユーザーを別々のプロジェクトにすることを強く推奨します。
デフォルトの 認可 設定では、管理ユーザーのみが他のプロジェクトのリソースを作成できます。OpenStack では以下の 2 種類の認可ポリシーを使うことができます。
ポリシーエンジンは policy.json
ファイルから項目を読み込みます。このファイルの実際の位置はディストリビューションにより異なります。一般的に Nova 用の設定ファイルは /etc/nova/policy.json
にあります。システムの実行中に項目を更新でき、サービスを再起動する必要がありません。今のところ、ポリシーファイルの編集がこのようなポリシーを更新する唯一の方法です。
OpenStack サービスのポリシーエンジンがポリシーと直接照合を行います。ルールはそのようなポリシーの要素の評価を意味します。たとえば、 compute:create: "rule:admin_or_owner"
文において、ポリシーは compute:create
で、ルールは admin_or_owner
です。
ポリシーのいずれかが OpenStack API 操作、もしくは指定された操作で使用されている特定の属性に一致する場合、ポリシーが OpenStack ポリシーエンジンにより呼び出されます。たとえば、ユーザーが POST /v2/{tenant_id}/servers
リクエストを OpenStack Compute API サーバーに送信したときに必ず、エンジンが create:compute
ポリシーを評価します。ポリシーは特定の API 拡張 に関連づけることもできます。たとえば、ユーザーが compute_extension:rescue
のような拡張に対して要求を行った場合、プロバイダー拡張により定義された属性は、その操作に対するルールテストを呼び出します。
認可ポリシーは、一つまたは複数のルールにより構成できます。複数のルールを指定すると、いずれかのルールが成功と評価されれば、評価エンジンが成功になります。API 操作が複数のポリシーに一致すると、すべてのポリシーが成功と評価される必要があります。認可ルールは再帰的にもできます。あるルールにマッチした場合、これ以上展開できないルールに達するまで、そのルールは別のルールに展開されます。以下のルールが定義できます。
"role:admin"
が成功します。true
に設定されている場合、 "field:networks:shared=True"
が成功します。"tenant_id:%(tenant_id)s"
が成功します。これは標準の nova policy.json
ファイルの抜粋です。
{
"context_is_admin": "role:admin",
"admin_or_owner": "is_admin:True", "project_id:%(project_id)s", ~~~~(1)~~~~
"default": "rule:admin_or_owner", ~~~~(2)~~~~
"compute:create": "",
"compute:create:attach_network": "",
"compute:create:attach_volume": "",
"compute:get_all": "",
"admin_api": "is_admin:True",
"compute_extension:accounts": "rule:admin_api",
"compute_extension:admin_actions": "rule:admin_api",
"compute_extension:admin_actions:pause": "rule:admin_or_owner",
"compute_extension:admin_actions:unpause": "rule:admin_or_owner",
...
"compute_extension:admin_actions:migrate": "rule:admin_api",
"compute_extension:aggregates": "rule:admin_api",
"compute_extension:certificates": "",
...
"compute_extension:flavorextraspecs": "",
"compute_extension:flavormanage": "rule:admin_api", ~~~~(3)~~~~
}
policy.json
のどのポリシーとも一致しなかった場合に、必ず評価される規定のポリシーを表します。いくつかの場合では、いくつかの操作を管理者のみに制限すべきです。そこで、次の例では、ユーザーが自分のフレーバーを作成できるようにするシナリオの場合に、このサンプルのポリシーファイルをどのように変更すればよいかを示します。
"compute_extension:flavormanage": "",
クラウドのユーザーは他のユーザーに悪影響を与える場合があります。意図的に悪意を持って行わる場合もあれば、偶然起こる場合もあります。状況を理解することにより、このような混乱に対処する方法について、よりよい判断をできるようになります。
例えば、あるユーザーのグループが、非常に計算負荷の高い作業用に大量のコンピュートリソースを使うインスタンスを持っているとします。これにより、Compute ノードの負荷が高くなり、他のユーザーに影響を与えます。この状況では、ユーザーのユースケースを精査する必要があります。計算負荷が高いシナリオがよくあるケースだと判明し、ホスト集約やリージョンなど、クラウドを適切に分割することを計画すべき場合もあるでしょう。
別の例は、あるユーザーが非常に多くの帯域を消費することです。繰り返しですが、ユーザーが実行していることを理解することが重要です。必ず多くの帯域を使用する必要があれば、他のユーザーに影響を与えないように通信帯域を制限する、または、より多くの帯域を利用可能な別の場所に移動させる必要があるかもしれません。一方、ユーザーのインスタンスが侵入され、DDOS 攻撃を行っているボットネットの一部になっているかもしれません。この問題の解決法は、ネットワークにある他のサーバーが侵入された場合と同じです。ユーザーに連絡し、対応する時間を与えます。もし対応しなければ、そのインスタンスを停止します。
最後の例は、ユーザーがクラウドのリソースに繰り返し悪影響を与える場合です。ユーザーと連絡をとり、何をしようとしているのか理解します。ユーザー自身が実行しようとしていることを正しく理解していない可能性があります。または、アクセスしようとしているリソースに問題があり、リクエストがキューに入ったり遅れが発生している場合もあります。
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.