コンパートメントの作業
コンパートメントを使用してOCIでクラウド・リソースを編成する方法をご紹介します。
Oracle Cloud Infrastructureの操作を最初に開始する場合、コンパートメントを使用してクラウドのリソースを編成および分離する方法について慎重に検討する必要があります。コンパートメントは、そのプロセスの基本となります。ほとんどのリソースは、コンパートメント間で移動できます。ただし、何かを実装する前に、組織のコンパートメント設計を事前に考えることが重要です。詳細は、テナンシを設定するためのベスト・プラクティスについて学習を参照してください。
コンソールは現在のリージョン内のコンパートメント別にリソースを表示するよう設計されています。コンソールでリソースを操作する場合、ページ上のリストから作業するコンパートメントを選択する必要があります。このリストは、アクセス権限のあるテナンシ内のコンパートメントのみが表示されるようにフィルタされています。管理者である場合、すべてのコンパートメントを表示し、すべてのコンパートメントのリソースを操作する権限を持ちますが、アクセス権が制限されているユーザーはそうではない可能性があります。
コンパートメントはテナンシ全体で複数のリージョンにわたります。コンパートメントを作成すると、テナンシをサブスクライブしているすべてのリージョンで使用可能になります。テナンシ・エクスプローラを使用して、特定のコンパートメントのリソースのクロスリージョン・ビューを取得できます。コンパートメント内のすべてのリソースの表示を参照してください。
セキュリティを強化するために、コンパートメントをセキュリティ・ゾーンに関連付けることができます。詳細は、セキュリティ・ゾーンを参照してください。
ここでは、次のトピックについて説明します。
コンパートメントのアクセス制御
コンパートメントの作成後、少なくとも1つのポリシーを記述する必要があります。そうしないと、アクセスできません(テナンシ・レベルで権限が設定された管理者またはユーザーを除く)。別のコンパートメント内にコンパートメントを作成すると、コンパートメントは階層の上位コンパートメントからアクセス権限を継承します。詳細は、ポリシー継承を参照してください。
アクセス・ポリシーを作成する場合、アタッチ先のコンパートメントを指定する必要があります。これにより、ポリシーを後で変更または削除できるユーザーが制御されます。コンパートメント階層がどのように設計されているかに応じて、テナンシ、親、または特定のコンパートメント自体にアタッチできます。詳細は、ポリシー・アタッチメントを参照してください。
コンパートメントへのリソースの配置
新規リソースをコンパートメントに配置するには、リソースの作成時にコンパートメントを指定するだけです(コンパートメントは、リソースを作成するために必要な情報の1つです)。コンソールで作業している場合は、リソースを作成するコンパートメントを表示していることを確認します。ほとんどのIAMリソースはテナンシ(これには、ユーザー、グループ、コンパートメントおよびテナンシにアタッチされたポリシーが含まれます)に存在し、特定のコンパートメントで作成したり、管理することはできないことに注意してください。
コンパートメント内のリソースの検出
リソース・マネージャでは、リソース検出を使用して、デプロイされたリソースをTerraform構成ファイルおよび状態ファイルとして取得できます。作成されたスタックは、ITインフラストラクチャを「Infrastructure as Code」としてプログラムで管理、バージョニングおよび永続化するために使用できるTerraform構成を提供します。
コンパートメントから作成されたスタックは、コンパートメント全体でサポートされているリソースのすべてを適切なスコープで表します。テナンシのルート・コンパートメントを選択した場合、スコープはユーザーやグループなどのテナンシ・レベルになります。非ルート・コンパートメントを選択した場合、スコープはコンピュート・インスタンスなどのコンパートメント・レベルになります。
スタックの作成は、単一のコンパートメントからのみサポートされます。ネストされたコンパートメントからスタックを作成することはできません。
手順については、既存のコンパートメントからのスタックの作成を参照してください。
コンパートメント移動の影響
同じテナンシ内の異なる親コンパートメントにコンパートメントを移動できます。コンパートメントを移動すると、そのすべての内容(サブコンパートメントおよびリソース)も一緒に移動されます。コンパートメントを移動すると内容も含まれます。これらについては、後続の各項で説明します。コンパートメントを移動する前にこれらの点に注意してください。
必須IAMポリシー
コンパートメントを移動するには、現在のコンパートメントおよび宛先コンパートメントの最下位の共有親コンパートメントに対するmanage all-resources権限を持つグループに属している必要があります。
コンパートメントの移動に関する制限事項
- ソースまたは宛先がセキュリティ・ゾーンの一部である場合は、コンパートメントを移動できません。セキュリティ・ゾーン内でコンパートメントを管理するには、セキュリティ・ゾーン・コンソールを使用する必要があります。
-
移動対象のコンパートメントと同じ名前のコンパートメントにコンパートメントを移動することはできません。
たとえば、コンパートメントAとコンパートメントBの両方がルート・コンパートメント下にあるとします。コンパートメントAはサブコンパートメントで、コンパートメントBとも呼ばれます。コンパートメントBを親コンパートメントBに移動することはできません。
項目 説明 
同じ親コンパートメント内にある2つのコンパートメントの名前を同じにすることはできません。したがって、同じ名前のコンパートメントがすでに存在する宛先コンパートメントにコンパートメントを移動することはできません。
コンパートメント移動時のポリシーの理解
コンパートメントを新しい親コンパートメントに移動すると、新しい親のアクセス・ポリシーが有効になり、前の親のポリシーは適用されなくなります。コンパートメントを移動する前に、次のことを確認してください。
- 現在の位置にあるコンパートメントへのアクセスを制御するポリシーを認識しています。
- コンパートメントを移動すると有効になる新しい親コンパートメント内のポリシーを認識しています。
階層を指定するポリシーとともにネストされたコンパートメントを移動する場合によっては、一貫性を確保するためにポリシーが自動的に更新されます。
ポリシーの例
現在のコンパートメントでの権限を持つグループのアクセス権の消失。宛先コンパートメントでの権限を持つグループのアクセス権の取得
次の図は、A:Bの子であるコンパートメントCを階層A:Dに移動するコンパートメント階層を示しています。
| 項目 | 説明 |
|---|---|
|
テナンシには、コンパートメントBおよびDに対して次のポリシーが定義されています。 Policy1: |
 |
コンパートメントCがBからDに移動された場合の影響: Policy2: |
-
グループG1は、コンパートメントC内のinstance-familiesを管理できなくなります。
-
グループG2は、コンパートメントCでinstance-familiesを管理できるようになります。
コンパートメントの移動時に権限が失われるグループだけでなく、権限を取得するグループも認識していることを確認します。
ポリシーの自動更新
コンパートメントを移動すると、一部のポリシーが自動的に更新されます。移動対象のコンパートメントまでコンパートメント階層を指定するポリシーは、現在とターゲットの親の共有祖先にポリシーがアタッチされると自動的に更新されます。次に例を示します。
例1:ポリシーが自動的に更新される
| 項目 | 説明 |
|---|---|
|
ポリシー: |
|
ポリシー: |
 |
ポリシーは自動的に更新されます。グループG1は権限が失われません。 |
この例では、コンパートメントAを「Operations:Test」から「Operations:Dev」に移動します。コンパートメントAを管理するポリシーは、共有の親「Operations」にアタッチされます。コンパートメントが移動されると、新規コンパートメントの場所を指定するために、IAMサービスによってポリシー・ステートメントが自動的に更新されます。
グループG1がそのロケーションのコンパートメントAに引き続きアクセスできるようにするために、手動操作は不要です。
例2:ポリシーが更新されていない
| 項目 | 説明 |
|---|---|
|
ポリシー: グループG1にコンパートメントAのバケットの管理を許可します |
|
ポリシー: グループG1にコンパートメントAのバケットの管理を許可します |
|
ポリシーは更新されません。グループG1はこの権限が失われます。このポリシーは無効であるため、手動で削除する必要があります。 |
この例では、コンパートメントAを「Operations:Test」から「Operations:Dev」に移動します。ただし、コンパートメントAを管理するポリシーは、テスト・コンパートメントに直接アタッチされます。ポリシーは、コンパートメントが移動されても自動的に更新されません。コンパートメントAを指定するポリシーは有効ではなくなります。手動で削除する必要があります。グループG1は、「Dev」の下の新規のロケーションにあるコンパートメントAにアクセスできなくなります。別の既存のポリシーによってグループG1へのアクセス権が付与されないかぎり、G1がコンパートメントA内のバケットを引き続き管理できるように、新しいポリシーを作成する必要があります。
例3:テナンシにアタッチされているポリシーが更新される
| 項目 | 説明 |
|---|---|
|
ポリシー: グループG1にコンパートメントOperations:Test:Aのバケットの管理を許可します |
|
ポリシー: グループG1にコンパートメントHR:Prod:Aのバケットの管理を許可します |
|
ポリシーは自動的に更新されます。グループG1は権限が失われません。 |
この例では、コンパートメントAを「Operations:Test」から「HR:Prod」に移動します。コンパートメントAを管理するポリシーはテナンシにアタッチされていますが、これは元の親コンパートメントと新規親コンパートメントによって共有されている祖先です。そのため、コンパートメントが移動されると、新規コンパートメントの場所を指定するためにIAMサービスによってポリシー・ステートメントが自動的に更新されます。
コンパートメント移動時のコンパートメント割当ての理解
あるコンパートメントを別のコンパートメントに移動すると、宛先コンパートメントのリソース割当ては検証されず、強制されません。したがって、コンパートメントを移動すると宛先コンパートメントの割当て違反になる場合、移動はブロックされません。移動が完了すると、宛先コンパートメントは割当て超過状態になります。宛先コンパートメントの割当てを調整するか、既存の割当てに準拠してリソースを削除するまで、割当てを超えて新しいリソースを作成することはできません。コンパートメント割当ての管理の詳細は、コンパートメント割当ての概要を参照してください。
コンパートメント移動時のタグ付けの理解
タグは、コンパートメントの移動後に自動的に更新されません。コンパートメントに基づいてタグ付け戦略を実装している場合、移動後にリソースのタグを更新する必要があります。たとえば、CompartmentAにCompartmentBという子コンパートメントがあるとします。CompartmentAは、CompartmentAのすべてのリソースがTagAでタグ付けされるように、タグのデフォルトを使用して設定されています。そのため、CompartmentBとそのすべてのリソースには、デフォルトのタグであるTagAのタグが付けられます。CompartmentBをCompartmentCに移動しても、CompartmentAからデフォルトのタグがそのまま使用されます。CompartmentCのデフォルトのタグを設定した場合、移動したコンパートメントのリソースにそれらのタグを追加する必要があります。
| 項目 | 説明 |
|---|---|
|
CompartmentBのすべてのリソースは、その親CompartmentAに定義されているデフォルトのタグでタグ付けされます。 |
|
CompartmentBをCompartmentCに移動しても、デフォルトのタグは更新されません。CompartmentBには、CompartmentAからのデフォルトのタグがそのまま適用されます。 |