ユーザー管理¶

OpenStack Dashboard はユーザーを管理するグラフィカルインターフェースを提供します。このセクションは Dashboard を用いたユーザー管理を説明します。

コマンドラインクライアントからプロジェクト、ユーザー、ロールを管理することもできます。

さらに、多くのサイトは個別の要求を満たすために独自ツールを作成し、サイト固有のポリシーを適用し、パッケージツールでは実現できないレベルのセルフサービスをユーザーに提供しています。

新規ユーザーの作成¶

ユーザーを作成するには、以下の情報が必要です。

ユーザー名
説明
電子メールアドレス
パスワード
主プロジェクト
ロール
有効

ユーザー名と電子メールアドレスは見たとおりです。あなたのサイトは従うべき独自ルールがあるかもしれません。主プロジェクトは単にユーザーが割り当てられる最初のプロジェクトです。ユーザーを作成する前に存在している必要があります。役割は多くの場合ずっと "メンバー" のままになります。標準の状態で、OpenStack は次の 2 つの役割が定義されています。

member: 一般的なユーザー
admin: すべてのプロジェクトにわたり全権限を持つ管理ユーザー。非常に注意して使用する必要があります。

他の役割を定義できますが、一般的にはそうしません。

一度この情報を収集すると、ダッシュボードでのユーザーの作成は、これまでに見てきた他の Web フォームと同じです。ユーザー管理ナビゲーションバーのユーザーリンクにあります。そして、右上にあるユーザーの作成ボタンをクリックします。

ユーザー情報の変更は、このユーザーページから実行することもできます。かなり多くのユーザーがいるならば、このページにはたくさんのユーザーが表示されることでしょう。ページの上部にあるフィルター検索ボックスを使うと、表示されるユーザーの一覧を絞り込むことができます。変更しようとしているユーザーの行末にあるアクションドロップダウンメニューの編集を選択することにより、ユーザー作成ダイアログと非常に似ているフォームを表示できます。

プロジェクトへのユーザーの割り当て¶

多くのサイトは一つのプロジェクトのみに割り当てられているユーザーで実行しています。これは、管理者にとってもユーザーにとっても、より保守的で分かりやすい選択です。管理の面では、ユーザーからインスタンスやクォータに関する問題の報告があった場合、どのプロジェクトに関するものかが明確です。ユーザーが一つのプロジェクトのみに所属している場合、ユーザーがどのプロジェクトで操作しているのかを気にする必要がありません。ただし、既定の設定では、どのユーザーも同じプロジェクトにいる他のユーザーのリソースに影響を与えることができることに注意してください。あなたの組織にとって意味があるならば、ユーザーを複数のプロジェクトに割り当てることも可能です。

既存のユーザーを追加のプロジェクトに割り当てる、または古いプロジェクトから削除することは、以下のスクリーンショットにあるとおり、ダッシュボードのプロジェクトページから、アクション列のユーザーの変更を選択することにより実行できます。

このビューから、数多くの有用な操作、いくつかの危険な操作を実行できます。

すべてのユーザー (All Users) という見出しが付けられた、このフォームの最初の列に、このプロジェクトにまだ割り当てられていない、クラウドのすべてのユーザーが一覧表示されます。2 列目には、すべての割り当て済みユーザーが一覧表示されます。これらの一覧は非常に長い可能性があります。しかし、それぞれの列の上部にあるフィルターフィールドに、探しているユーザー名の部分文字列を入力することにより、表示を絞り込むことができます。

ここから、プロジェクトにユーザーを追加するには + アイコンをクリックします。削除するには - をクリックします。

危険な点としては、メンバーの役割を変更する機能があることです。これはプロジェクトメンバー一覧のユーザー名の後ろにあるドロップダウンリストです。事実上すべての場合で、この値はメンバーに設定されています。この例では意図的に、この値が admin になっている管理ユーザーを示しています。

警告

管理者はプロジェクトごとではなく、グローバルです。そのため、ユーザーに admin ロールを与えることにより、クラウド全体にわたるユーザー管理権限を与えることになります。

一般的な使用法は、一つのプロジェクトだけに管理ユーザーを所属させることです。慣例により、"admin" プロジェクトがクラウド環境のセットアップ中に標準で作成されます。管理ユーザーもクラウドを使用してインスタンスの起動、管理を行う場合には、管理アクセスと一般アクセス用に別々のユーザーアカウントを使用し、それらのユーザーを別々のプロジェクトにすることを強く推奨します。

権限のカスタマイズ¶

デフォルトの認可設定では、管理ユーザーのみが他のプロジェクトのリソースを作成できます。OpenStack では以下の 2 種類の認可ポリシーを使うことができます。

操作ベース: 特定の操作に対するアクセス基準を指定するポリシー。特定の属性に対する詳細な制御も可能です。
リソースベース: リソースに対して設定されたパーミッションに基づいて、特性のリソースに対するアクセスを許可するかを決定する (今のところネットワークリソースでのみ利用可能)。OpenStack により強制される実際の認可ポリシーは、導入の仕方により異なります。

ポリシーエンジンは 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" が成功します。
項目に基づいたルール: 現在のリクエストに指定されたリソースの項目が指定された値と一致すれば、成功と評価されます。たとえば、ネットワークリソースの shared 属性が 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",
   "default": "rule:admin_or_owner",
   "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",
}

`admin_or_owner`は現在のユーザーが、管理者、またはリクエストで指定されたリソースの所有者 (テナント識別子が同じ) であれば、成功であると評価されるルールを表します。
default はAPI 操作が policy.json のどのポリシーとも一致しなかった場合に、必ず評価されるデフォルトのポリシーを表します。
compute_extension:flavormanage はフレーバーを操作する権限を、管理 API を使用する管理者だけに限定するポリシーを表します。

いくつかの場合では、いくつかの操作を管理者のみに制限すべきです。そこで、次の例では、ユーザーが自分のフレーバーを作成できるようにするシナリオの場合に、このサンプルのポリシーファイルをどのように変更すればよいかを示します。

{
  "compute_extension:flavormanage": ""
}

他のユーザーに悪影響を与えるユーザー¶

クラウドのユーザーは他のユーザーに悪影響を与える場合があります。意図的に悪意を持って行わる場合もあれば、偶然起こる場合もあります。状況を理解することにより、このような混乱に対処する方法について、よりよい判断をできるようになります。

例えば、あるユーザーのグループが、非常に計算負荷の高い作業用に大量のコンピュートリソースを使うインスタンスを持っているとします。これにより、Compute ノードの負荷が高くなり、他のユーザーに影響を与えます。この状況では、ユーザーのユースケースを精査する必要があります。計算負荷が高いシナリオがよくあるケースだと判明し、ホスト集約やリージョンなど、クラウドを適切に分割することを計画すべき場合もあるでしょう。

別の例は、あるユーザーが非常に多くの帯域を消費することです。繰り返しますが、ユーザーが実行していることを理解することが重要です。あるユーザが多くの帯域を使用する必要があれば、他のユーザーに影響を与えないように通信帯域を制限する、または、より多くの帯域を利用可能な別の場所に移動させる必要があるかもしれません。一方、あるユーザーのインスタンスが侵入され、DDOS 攻撃を行っているボットネットの一部になっているかもしれません。この問題の解決法は、ネットワークにある他のサーバーが侵入された場合と同じです。このユーザーに連絡し、対応する時間を与えます。もし対応しなければ、そのインスタンスを停止します。

最後の例は、ユーザーがクラウドのリソースに繰り返し悪影響を与える場合です。ユーザーと連絡をとり、何をしようとしているのか理解します。ユーザー自身が実行しようとしていることを正しく理解していない可能性があります。または、アクセスしようとしているリソースに問題があり、リクエストがキューに入ったりタイムラグが発生している場合もあります。

ユーザー管理