コンパートメントの管理

コンパートメントを作成する際には、親コンパートメント内で一意の名前(文字、数字、ピリオド、ハイフンおよびアンダースコアを含む、最大100文字)を指定する必要があります。また、コンパートメントの一意でない変更可能な説明である説明を1から400文字で指定する必要もあります。また、Oracleによって、コンパートメントにOracle Cloud IDと呼ばれる一意のIDが割り当てられます。詳細は、リソース識別子を参照してください。

コンパートメントにサブコンパートメントを作成して、6レベルの深さの階層を作成できます。

使用できるコンパートメント数の詳細は、サービス制限を参照してください。

コンパートメントの作成後、少なくとも1つのポリシーを記述する必要があります。そうしないと、アクセスできません(テナンシ・レベルで権限が設定された管理者またはユーザーを除く)。別のコンパートメント内にコンパートメントを作成すると、コンパートメントは階層の上位コンパートメントからアクセス権限を継承します。詳細は、ポリシー継承を参照してください。

アクセス・ポリシーを作成する場合、アタッチ先のコンパートメントを指定する必要があります。これにより、ポリシーを後で変更または削除できるユーザーが制御されます。コンパートメント階層がどのように設計されているかに応じて、テナンシ、親、または特定のコンパートメント自体にアタッチできます。詳細は、ポリシー・アタッチメントを参照してください。

新規リソースをコンパートメントに配置するには、リソースの作成時にコンパートメントを指定するだけです(コンパートメントは、リソースを作成するために必要な情報の1つです)。コンソールで作業している場合は、リソースを作成するコンパートメントを表示していることを確認します。ほとんどのIAMリソースはテナンシ(これには、ユーザー、グループ、コンパートメントおよびテナンシにアタッチされたポリシーが含まれます)に存在し、特定のコンパートメントで作成したり、管理することはできないことに注意してください。

ほとんどのリソースは、作成後に移動できます。あるコンパートメントから別のコンパートメントに移動できないリソースがいくつかあります。また、特定のリソースは、安全性が低下する可能性があるため、セキュリティ・ゾーンから同じセキュリティ・ゾーン内にないコンパートメントに移動することはできません。セキュリティ・ゾーンのリソースに関する制限の詳細は、リソース移動の制限を参照してください。

リソースの依存関係がアタッチされているリソース、およびアタッチされていないリソースがあります。アタッチされた依存関係がすべて、親リソースの移動時に同じように動作するわけではありません。

一部のリソースでは、アタッチされた依存関係が親リソースとともに新規コンパートメントに移動します。親リソースはすぐに移動しますが、場合によってはアタッチされた依存関係が非同期に移動し、移動が完了するまで新規コンパートメントに表示されないことがあります。

他のリソースの場合、アタッチされたリソースの依存関係は新規コンパートメントに移動しません。これらのアタッチされたリソースは個別に移動できます。

リソースを新規コンパートメントに移動すると、新規コンパートメントを制御するポリシーがただちに適用され、リソースへのアクセスに影響します。コンパートメント組織の構造に応じて、測定、請求およびアラームも影響を受ける可能性があります。

各リソースとそのアタッチメントの動作について理解するために、個々のリソースのサービス・ドキュメントを参照してください。

単一のAPIコールを使用してコンパートメント内のすべてのリソースのリストを取得することはできません。かわりに、コンパートメント内の特定のタイプのすべてのリソース(たとえば、すべてのインスタンス、すべてのブロック・ストレージ・ボリュームなど)をリストできます。

コンパートメントを削除するには、すべてのリソースが空である必要があります。コンパートメントの削除を開始する前に、そのすべてのリソースが、コンパートメントにアタッチされたポリシーを含めて移動、削除または終了していることを確認してください。

削除アクションは非同期のため、作業リクエストを開始します。作業リクエストが実行中に、コンパートメントの状態が「削除中」に変更されます。通常、作業リクエストが完了するのに数分かかります。「削除中」状態の場合、コンパートメント・ピッカーに表示されません。作業リクエストが失敗した場合、コンパートメントは削除されず、「アクティブ」状態に戻ります。

コンパートメントが削除されると、その状態は「削除済」に更新され、名前にランダムな文字列が追加されます。たとえば、CompartmentAがCompartmentA.qR5hP2BDになることがあります。コンパートメントの名前を変更すると、元の名前を別のコンパートメント用に再利用できます。Oracleでは、削除されたコンパートメントが90日間「コンパートメント」ページに表示されます。削除されたコンパートメントは、コンパートメント・ピッカーから削除されます。削除されたコンパートメントを参照するポリシー・ステートメントがある場合、ポリシー・ステートメント内の名前が新しい名前に更新されます。

コンパートメントをリカバリするには、まず「コンパートメント」ページのリストから選択する必要があります。削除されたコンパートメントを表示するために、状態フィルタを使用する必要がある場合があります。削除されたコンパートメントは、元のコンパートメント名にランダムな文字列を追加して名前変更されていることに注意してください。たとえば、CompartmentAはCompartmentA.qR5hP2BDのようになります。Oracleでは、削除されたコンパートメントが90日間「コンパートメント」ページに表示されます。

削除されたコンパートメントをリカバリしても、その名前は変わりません。たとえば、CompartmentA.qR5hP2BDという名前の削除済コンパートメントをリカバリしても、名前は変わりません。ポリシー・ステートメントは削除済コンパートメントの新しい名前を使用するように更新されるため、削除済コンパートメントを参照していたポリシー・ステートメントは、リカバリされたコンパートメントを参照するようになります。

タグのデフォルトを使用すると、現在のコンパートメントで、作成時にすべてのリソースに自動的に適用されるタグを指定できます。詳細は、タグのデフォルトの管理を参照してください。

コンパートメントを移動するには、現在のコンパートメントおよび宛先コンパートメントの最下位の共有親コンパートメントに対するmanage all-resources権限を持つグループに属している必要があります。

• ソースまたは宛先がセキュリティ・ゾーンの一部である場合は、コンパートメントを移動できません。セキュリティ・ゾーン内でコンパートメントを管理するには、セキュリティ・ゾーン・コンソールを使用する必要があります。

• 移動対象のコンパートメントと同じ名前のコンパートメントにコンパートメントを移動することはできません。

  たとえば、コンパートメントAとコンパートメントBの両方がルート・コンパートメント下にあるとします。コンパートメントAはサブコンパートメントで、コンパートメントBとも呼ばれます。コンパートメントBを親コンパートメントBに移動することはできません。

  

• 同じ親の2つのコンパートメントに同じ名前を付けることはできません。したがって、同じ名前のコンパートメントがすでに存在する宛先コンパートメントにコンパートメントを移動することはできません。

コンパートメントを新しい親コンパートメントに移動すると、新しい親のアクセス・ポリシーが有効になり、前の親のポリシーは適用されなくなります。コンパートメントを移動する前に、次のことを確認してください。

• 現在の位置にあるコンパートメントへのアクセスを制御するポリシーを認識しています。
• コンパートメントを移動すると有効になる新しい親コンパートメント内のポリシーを認識しています。

階層を指定するポリシーとともにネストされたコンパートメントを移動する場合によっては、一貫性を確保するためにポリシーが自動的に更新されます。

次の図は、A:Bの子であるコンパートメントCを階層A:Dに移動するコンパートメント階層を示しています。

テナンシには、コンパートメントBおよびDに対して次のポリシーが定義されています。

Policy1: Allow group G1 to manage instance-family in compartment A:B

Policy2: Allow group G2 to manage instance-family in compartment A:D

コンパートメントCがBからDに移動された場合の影響:

グループG1は、コンパートメントC内のinstance-familiesを管理できなくなります。

グループG2は、コンパートメントCでinstance-familiesを管理できるようになります。

コンパートメントの移動時に権限が失われるグループだけでなく、権限を取得するグループも認識していることを確認します。

コンパートメントを移動すると、一部のポリシーが自動的に更新されます。移動対象のコンパートメントまでコンパートメント階層を指定するポリシーは、現在とターゲットの親の共有祖先にポリシーがアタッチされると自動的に更新されます。次に例を示します。

例1:ポリシーが自動的に更新される

この例では、コンパートメントAを「Operations:Test」から「Operations:Dev」に移動します。コンパートメントAを管理するポリシーは、共有の親「Operations」にアタッチされます。コンパートメントが移動されると、新規コンパートメントの場所を指定するために、IAMサービスによってポリシー・ステートメントが自動的に更新されます。

ポリシー

Allow group G1 to manage buckets in compartment Test:A 

更新

Allow group G1 to manage buckets in compartment Dev:A

グループG1がそのロケーションのコンパートメントAに引き続きアクセスできるようにするために、手動操作は不要です。

例2:ポリシーが更新されていない

この例では、コンパートメントAを「Operations:Test」から「Operations:Dev」に移動します。ただし、コンパートメントAを管理するポリシーは、テスト・コンパートメントに直接アタッチされます。コンパートメントが移動されても、ポリシーは自動的に更新されません。コンパートメントAを指定するポリシーは有効ではなくなります。手動で削除する必要があります。グループG1は、「Dev」の下の新規のロケーションにあるコンパートメントAにアクセスできなくなります。別の既存のポリシーによってグループG1へのアクセス権が付与されないかぎり、G1がコンパートメントA内のバケットを引き続き管理できるように、新しいポリシーを作成する必要があります。

例3:テナンシにアタッチされているポリシーが更新される

この例では、コンパートメントAを「Operations:Test」から「HR:Prod」に移動します。コンパートメントAを管理するポリシーはテナンシにアタッチされていますが、これは元の親コンパートメントと新規親コンパートメントによって共有されている祖先です。そのため、コンパートメントが移動されると、新規コンパートメントの場所を指定するためにIAMサービスによってポリシー・ステートメントが自動的に更新されます。

ポリシー・ステートメントは次のようになります。

Allow group G1 to manage buckets in compartment Operations:Test:A 

更新

Allow group G1 to manage buckets in compartment HR:Prod:A

グループG1がコンパートメントAに引き続きアクセスできるようにするために、手動操作は不要です。

あるコンパートメントを別のコンパートメントに移動すると、宛先コンパートメントのリソース割当ては検証されず、強制されません。したがって、コンパートメントを移動すると宛先コンパートメントの割当て違反が発生する場合、移動はブロックされません。移動が完了すると、宛先コンパートメントは割当て超過状態になります。宛先コンパートメントの割当てを調整するか、既存の割当てに準拠してリソースを削除するまで、割当てを超えて新しいリソースを作成することはできません。コンパートメント割当ての管理の詳細は、コンパートメント割当ての概要を参照してください。

タグは、コンパートメントの移動後に自動的に更新されません。コンパートメントに基づいてタグ付け戦略を実装している場合、移動後にリソースのタグを更新する必要があります。たとえば、CompartmentAにCompartmentBという子コンパートメントがあるとします。CompartmentAは、CompartmentAのすべてのリソースがTagAでタグ付けされるように、タグのデフォルトを使用して設定されています。そのため、CompartmentBとそのすべてのリソースには、デフォルトのタグであるTagAのタグが付けられます。CompartmentBをCompartmentCに移動しても、CompartmentAからデフォルトのタグがそのまま使用されます。CompartmentCのデフォルトのタグを設定した場合、移動したコンパートメントのリソースにそれらのタグを追加する必要があります。