CloudStackを本格的に使用する場合、ドメイン、アカウント、ユーザを作成しなくてはならないが、それらについてまず理解しておく必要がある。
そこで、以下のサイトを翻訳してみた。
Accounts, Domains, and Admin explained
以下、翻訳した文章である。
（参照の際はat your own riskでお願いします）
ここから－－－－－－－－
アカウント、ドメイン、管理者の説明
ドメインは複数のアカウントを保有する事ができます。各アカウントは複数のユーザを保有することができる。リソースの所有権はアカウントにひも付けされます。ユーザとは、丁度銀行口座において異なる利用者が銀行口座に対して参照権限をもつような、アカウントリソースへアクセススするための単なる同義語です。それぞれのユーザパスワードを持ちますが、同一の預金口座資金を使用します。CloudStack UIでアカウントやユーザを作成することで、より深く理解できるでしょう。
詳細
- １つのユーザは１つのアカウントにのみ所属することができます。同じユーザが複数のアカウントに所属することはできません。
- どんなドメインレベルでアカウントを作成する場合でも、アカウントは、管理者(admin)と利用者(user)の２つのタイプがあります。もしアカウントが管理者(admin)の場合はそのドメインのドメイン管理者となります、そしてもしアカウントが利用者(user)である場合はそのドメインの一般ユーザとなります。
- ROOTレベルで作成された管理者(admin)はルート管理者(ROOT admin)と呼称されます。ROOTがトップドメインなので、ルート管理者はすべてのリソースに対する操作特権を保有することとなります。
- ユーザ名は所属するアカウントのドメイン内で一意となります。異なるドメイン（サブドメイン含む）であれば同じユーザ名が存在してもかまいません。
- ドメイン名はフルパスが一意であれば同じドメイン名をつけることができます（例：ROOT/d1の場合、ROOT/foo/d1やROOT/bar/d2）。
- リソースは、アカウント内の個々のユーザではなく、１つのアカウントの所属となります。課金やリソース制限などはゆーざごとではなくアカウントごとに管理されます。
- CloudStackは、管理者(admin)アカウント、ドメイン管理者(domain-admin)アカウント、ユーザアカウントの3つの異なるタイプのアカウントの作成を許しています。すべてのロール（管理者(admin)、ドメイン管理者(domain admin)、ユーザ(user)）はアカウントレベルに割り当てられます。CloudStack UI上で作成してそれぞれの違いを理解して下さい。
- あるアカウントのすべてのユーザは同じ特権を保有します。１つのアカウントの役割ベースのユーザは存在しません。
- 同一ドメインに複数の管理者を保有することができます。すべてのドメインはROOTドメイン以下に作成されます。
ここまで－－－－－－－－
アカウントは、いわゆるパーティパターンの"パーティ"に相当し、個人１名をあらわすことも部署などのグループを表すこともできる設計になっている。
ドメインもグループを表す論理単位なのだが、ドメイン間でのリソースが共用できないようなので、それこそクラウドビジネスでIaaSとしてCloudStackリソースを提供する際の契約単位とかに利用するため設計されたのだろう。
社内IaaSで他社が出てこない場合は、１つのドメインでも運用はできそうだが、ルートドメインにインスタンス数上限などのリソース制約が切れない以上、ルート以外に１つドメインは切っておいたほうが良い。
アカウント、ドメインも複数の人間が参加する組織や団体をあらわす論理単位だけど、CloudStackには"プロジェクト"という論理単位も存在する。
このプロジェクトについても理解しておく必要があるため、CloudStack wikiをさがしてみた。
するとQ&Aに以下のドキュメントを発見した。
Accounts, Domains, and Projects oh my!
以下、翻訳した文章である。
（こちらも、参照の際はat your own riskでお願いします）
ここから－－－－－－－－
アカウント、ドメイン、そしてプロジェクト、なんとまあ！
ドメイン
ドメインは（会社や団体など）組織の単位とほぼ同じです。ドメインは、（一般的に）リソースを所有していませんが、しかしドメインはドメイン範囲内のすべてのアカウントに対しリソース制限を強制することができます。ドメインはプロジェクトやアカウントを収容することができます、しかしドメインは本当にドメイン自身だけでインスタンス、ボリューム、他のリソースなどを所有しません。ドメインは、インスタンス、ボリューム、ネットワーク、スナップショット、テンプレートなどのようなリソースを所有できるその他のもののための器（コンテナ）です。ドメインは親ドメインに対して一意でなくてはなりませんが、その他のドメインの子であるなら（同じドメイン名を）繰り返すことができます(ROOT/dom1/sub1とROOT/dom2/sub1は"sub1"が一意ではありませんがそれぞれの親が一意であるため使用することができます)。
ルート(ROOT)ドメイン
ルートドメインは、すべてのドメインがルートドメインの子となるため、少々特殊です。ルートドメインの管理者アカウントは、すべての子ドメインに所属する（すべてのドメインの意、なぜならすべてのドメインはルート(ROOT)の子であるため）その他のリソースを（API経由で）操作する権限を保有しています。このためルートドメインの管理者アカウントは全体管理権限を保有することとなります。
本文書記述時点では、CloudStackはロールベースアクセス制御(RBAC)をサポートしていませんが、２つのレベルのパーミッション、管理者(admin)と利用者(user)が存在しています。アカウント名は１つのドメイン内で一意でなくてはなりませんが、すべてのドメインに対して一意でなくてもかまいません（joe@foo.tldとjoe@bar.tldは、"joe"が一意ではありませんが、foo.tldとbar.tldが一意ではないため、使用することができます）。
管理者アカウント
管理者アカウントはドメイン管理権限を保有しています。管理者アカウントは、ルート管理者により対象のドメインに対しドメイン制約（許可されるインスタンス数、ボリューム数など）を強制されていますが、多くの特権を保有しています。例えば、ドメイン管理者はドメイン内にアカウントを追加や、ユーザのAPIキーを生成する事ができます。自身のドメインのサブドメインを作成したり、ドメイン内のリソース利用状況をレポートする事もできます。
利用者アカウント
利用者アカウントは新規のリソース（インスタンス、ボリューム、スナップショットなど）を作成する権限を保有していますが、管理特権はとても少ないです。アカウントはAPIキーを生成できませんし、アカウントへユーザを追加することもできません、参照することだけは可能です。利用者アカウントが使用できるすべてのコマンドリストはAPIガイドを参照して下さい。
ユーザ名、パスワード、APIキー
ユーザ名、パスワード、APIキーはアカウントに属します。Web UI からユーザ名とパスワードを用いて、（そしてもしAPIキーが生成されているのであれば、APIキーを用いて）ログインします。ユーザ名は所属するドメイン内で一意でなくてはなりません（foo.tldドメイン範囲内の２つのユーザは同じユーザ名を持つことはできません－２つのjoo@foo.tldユーザを持つことはできません）が、異なるドメインであれば可能です（joe@foo.tldとjoe@bar.tld）。ユーザはリソースを所有することはできません、所属するアカウントが所有するリソースへの操作やアクセスといった単純な使い方のみです。ユーザは個別のパーミッションを保有することができません、ユーザが所属するアカウントのパーミッションを受け継ぎます。
アカウントとリソース
アカウントはリソースを所有します。アカウントはリソースを所有します、重要なので二度いいました。もしアカウントを削除したならば、所有していたすべてのリソース（インスタンス、ボリューム、スナップショットなど）は同様に削除されます。利用状況はアカウントレベルでも追跡されます。このため、課金やチャージバック目的のためにusageモジュールが有効である場合、アカウントレベルでのリソース使用状況のレポーティングが有効となります。
プロジェクト
プロジェクトはアカウントに似ていますが、アカウントとは違い特別な一面を持っています。プロジェクトはリソースの制御を複数のアカウントで共有することができます。リソース自身（インスタンス、ボリューム、スナップショットなど）はプロジェクトにより所有され、同一ドメイン内の複数のアカウントによる操作が許可されます。このため、ある組織内の複数の部署で取り組んでいる共同業務があるのであれば、プロジェクトを作成し他のアカウント（組織内の部署）を招待することで共同業務への参加を促すことができます。プロジェクトでは１つのアカウントはプロジェクト管理権限を委任しなければなりません。プロジェクト管理者は、対象ドメイン内の他のアカウントを招待したりアクセスを取り消す権限があります。プロジェクト管理者のみが対象のプロジェクトの操作権限を保有し、その他の（対象プロジェクトにアクセス可能な）アカウントに対する権限（例えば、許可されているインスタンス数やボリューム数、スナップショット数など）を保有していません。プロジェクト管理者が１つだけである間は、対象のプロジェクトが所有しているがそれに参加している個々のアカウントではないプロジェクトによって作成されたすべてのリソースであるため、影響を及ぼさないでアカウント間で移動することができます。
ここまで－－－－－－－－
翻訳しているとき業務としてのプロジェクトとCloudStackの論理単位であるプロジェクトが混ざっていて読みにくい..
CloudStackの論理単位である"プロジェクト"は、ドメイン内の複数のアカウントでリソースを共有でき、しかもまだ参加していないアカウントを"招待"することができる。
なので、プロジェクトは実業務上のプロジェクトと同じ考え方で切るほうがよいだろう。
ただ、usage server を使う場合は、アカウントとプロジェクトという単位以外では使用状況が追跡できないということは、システム監査などがうるさい企業で使用する場合は１アカウント＝人間１人にして、１アカウント＝１ユーザを守って管理していったほうがよいかもしれない。
とすると１企業内で使用する場合の例として
| CloudStack 論理単位 |
実際の割り当て |
| ルート管理者 |
CloudStack管理を担当する人 |
| ドメイン |
会社名で１つ切る |
| ドメイン管理者 |
アカウントやリソース分配を管理する人 |
| アカウント |
社員１名 |
| ユーザ |
社員１名→LDAPユーザと対応 |
| プロジェクト |
社内の実プロジェクトと同じ単位、ドメイン管理者に作ってもらう |
| プロジェクト管理者 |
実プロジェクトの責任者アカウント、１名のみ。社員１名に紐付けないアカウントでも、責任者となる社員１名に割り当てても良い |
とか..かな。
プロジェクト管理者のプロジェクトビューのダッシュボード画面にはアカウントタブがあり、このタブの中でプロジェクト管理者権限を他のアカウントへ渡したり、（既存の）アカウントをプロジェクトメンバとして追加したりできます。
ちなみに以下のタイプモデルは、CloudStack4.1.1の管理コンソールを眺めて個人的に書いたものです。
図の中のアカウントの役割の管理者は"admin"、一般利用者は"user"をあらわしています。また、プロジェクトでの役割のプロジェクト管理者は"Admin"、一般プロジェクトメンバは"Regular"をあらわしています。
役割を表す構造がすこしきもちわるいので、ひょっとしたら将来的には関係主体・関係主体ロールのパターンに変更になるかもしれませんね。となると画面仕様も変更になるかも..まあ、想像ですが..
この図も参照の際はat your own riskでお願いします。
