第10章 プロジェクトとユーザーの管理

ダッシュボードからプロジェクトを追加する方法:

プロジェクト名と説明の入力が求められます（説明の入力は任意ですが、入力をお薦めします）。このプロジェクトを有効にするには、フォームの下にあるチェックボックスを選択します。これは標準で有効になっています。

プロジェクトメンバーを追加し、プロジェクトのクォータを調整することもできます。後述しますが、これらの操作を一度にすべて処理するほうが、実践的には非常に便利です。

コマンドラインインターフェース (CLI) からプロジェクトを作成する方法:

コマンドラインからのプロジェクト追加には、keystone ユーティリティを使用する必要があります。ここで「プロジェクト」の代わりに「テナント」を使用します。

# keystone tenant-create --name=demo

このコマンドは「demo」という名前のプロジェクトを作成します。--description <tenant-description>, を追加で指定することで、説明の文字列を付与できます。これは非常に便利です。また、コマンドに --enabled false を追加することにより、無効状態のグループを作成することもできます。標準で、プロジェクトは有効状態で作成されます。

デフォルトの認可設定では、管理ユーザーのみが他のプロジェクトのリソースを作成できます。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 操作が複数のポリシーに一致すると、すべてのポリシーが成功と評価される必要があります。また、認可ルールは再帰的にもできます。あるルールにマッチした場合、これ以上展開できないルールに達するまで、そのルールは別のルールに展開されます。以下のルールが定義できます。

これは標準の 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]
	}
	

[1] 現在のユーザーが、管理者、またはリクエストで指定されたリソースの所有者 (テナント識別子が同じ) であれば、成功であると評価されるルールを表します。

[2] API 操作が policy.json のどのポリシーとも一致しなかった場合に、必ず評価される規定のポリシーを表します。

[3] フレーバーを操作する権限を、管理 API を使用する管理者だけに限定するポリシーを表します。

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

"compute_extension:flavormanage": [ ],

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

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

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

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

システム管理の見過ごされがちな大事な要素の一つに、エンドユーザのためにシステム管理者が存在するという点があります。BOFH (Bastard Operator From Hell; 「地獄から来た最悪の管理者」) の道に入って、問題の原因となっているユーザーを全員停止させるようなことはしないでください。ユーザーがやりたいことを一緒になって理解し、どうするとあなたの環境がユーザーが目的を達成するのにもっと支援できるかを見つけてください。