テナンシをまたがったクラスタ関連リソースへのアクセス

1つのテナンシが他のテナンシのクラスタ関連リソースにアクセスできるようにするために必要なIAMポリシーについて学習します。

1つのテナンシが他のテナンシのリソースにアクセスする場合は、クロステナンシ・ポリシーを作成する必要があります。

ポリシーを初めて使用する場合は、ポリシーの開始および次を参照してください:

クロステナンシ・ポリシー

組織は、独自のテナントを持つ別の組織とクラスタ関連リソースを共有する場合があります。これは、会社内の別のビジネス・ユニット、会社の顧客、会社にサービスを提供する会社などの場合があります。このような場合、クラスタ作成およびデプロイメントのポリシー構成で説明されている必要なユーザー・ポリシーおよびサービス・ポリシーに加えて、クロステナンシ・ポリシーが必要です。

承認、許可および定義ステートメント

2つのテナンシ間でリソースにアクセスして共有するには、両方のテナンシの管理者は、アクセスと共有が可能なリソースを明示的に示す特別なポリシー・ステートメントを作成する必要があります。これらの特別なステートメントは、DefineEndorseおよびAdmitという語句を使用します。

クロステナンシ・ステートメントで使用される特別な動詞の概要は次のとおりです:

  • 承認: 独自のテナンシ内のグループが他のテナンシ内で実行できる一般的な機能セットを示します。承認ステートメントは、テナンシのリソースを使用する他のテナンシに対して境界を超えるユーザーのグループのテナンシに常に属します。例では、このテナンシはソース・テナンシと呼ばれます。
  • 許可: 別のテナンシからグループに付与する独自のテナンシの機能の種類を示します。Admitステートメントは、テナンシへのアクセスを許可するテナンシに属します。許可ステートメントは、ソース・テナンシからのリソース・アクセスを必要とし、対応する承認ステートメントで特定されるユーザーのグループを識別します。例では、このテナンシは宛先テナンシと呼ばれます。
  • Define: EndorseおよびAdmitポリシー・ステートメントのテナンシOCIDに別名を割り当てます。AdmitステートメントのソースIAMグループOCIDに別名を割り当てるには、宛先テナンシにDefineステートメントも必要です。

    定義ステートメントは、承認または許可ステートメントと同じポリシー・エンティティに含める必要があります。

承認および許可ステートメントは連携して動作しますが、それぞれのテナンシの別々のポリシーに存在します。アクセス権を指定する対応ステートメントがない場合、特定の承認または許可ステートメントはアクセス権を与えません。両方のテナンシから合意が必要です。

ソース・ポリシー

ソース管理者は、宛先テナンシでリソースを管理するためにソースIAMグループを承認するポリシー・ステートメントを作成します。

IAMグループのOKE-Adminsがテナンシ内のすべてのクラスタ関連リソースに対してすべての操作を実行することを承認する広範なポリシー・ステートメントの例を次に示します:

Endorse group OKE-Admins to manage cluster-family in any-tenancy

ソースIAMグループが宛先テナンシにクラスタを作成できるようにするには、ソース管理者がポリシー・ステートメントを作成して、仮想ネットワークを管理し、コンパートメントを検査するグループを承認する必要があります。例:

Endorse group OKE-Admins to manage virtual-network-family in any-tenancy
Endorse group OKE-Admins to inspect compartments in any-tenancy

テナンシ・アクセスの範囲を宛先テナンシのみに減らすポリシーを記述するには、ソース管理者が宛先テナンシのOCIDを宛先管理者から取得し、そのOCIDをポリシー・ステートメントに含める必要があります。次の例は、IAMグループOKE-AdminsがDestinationTenancyのクラスタ関連リソースのみを管理することを承認するポリシー・ステートメントを示しています:

Define tenancy DestinationTenancy as ocid1.tenancy.oc1..<unique_ID>
Endorse group OKE-Admins to manage cluster-family in tenancy DestinationTenancy

宛先ポリシー

宛先管理者は、次のポリシー・ステートメントを作成します:

  • ソース・テナントおよび宛先テナンシのリソースにアクセスできるIAMグループを定義します。ソース管理者は、ソース・テナンシのOCIDsおよびソースIAMグループを指定する必要があります。
  • ソースIAMグループに、宛先テナンシのクラスタ関連リソースへのアクセスを許可します。

ソース・テナンシのIAMグループのOKE-Adminsが宛先テナンシ内のすべてのクラスタ関連リソースに対してすべての操作を実行することを許可するポリシー・ステートメントの例を次に示します:

Define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
Define group OKE-Admins as ocid1.group.oc1..<unique_ID>
Admit group OKE-Admins of tenancy SourceTenancy to manage cluster-family in tenancy

ソースIAMグループが宛先テナンシにクラスタを作成できるようにするには、宛先管理者がポリシー・ステートメントを作成して、仮想ネットワークを管理し、宛先テナンシ内のコンパートメントを検査するグループを許可する必要があります。例:

Admit group OKE-Admins of tenancy SourceTenancy to manage virtual-network-family in tenancy
Admit group OKE-Admins of tenancy SourceTenancy to inspect compartments in tenancy

次の例は、ソース・テナンシのIAMグループのOKE-AdminsがSharedOKEClustersコンパートメント内のクラスタ関連リソースのみを管理することを承認するポリシー・ステートメントを示しています:

Define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
Define group OKE-Admins as ocid1.group.oc1..<unique_ID>
Admit group OKE-Admins of tenancy SourceTenancy to manage cluster-family in compartment SharedOKEClusters

管理対象ノード・プールの作成または更新時の他のテナンシのカスタム・イメージへのアクセス

CLIまたはAPIを使用して管理対象ノード・プールを作成または更新する場合は、Kubernetesエンジンがノード・プール内の管理対象ノードのプロビジョニングに使用するイメージのOCIDを指定します。カスタム・イメージのOCIDを指定する場合、カスタム・イメージはクラスタと同じテナンシにあるか、別のテナンシにある可能性があります。カスタム・イメージが異なるテナンシにある場合、他のテナンシにアクセスしてイメージを読み取ることができるようにするには、ポリシーが存在する必要があります。

Kubernetes Engineでカスタム・イメージを使用してプロビジョニングする管理対象ノード・プールを持つクラスタを含むテナンシ(ソース・テナンシ)で、ソース管理者は、宛先テナンシのカスタム・イメージへのアクセスを承認するポリシー・ステートメントを作成する必要があります。例:

Define tenancy image-tenancy as ocid1.tenancy.oc1...<unique_ID>
Endorse any-user to {INSTANCE_IMAGE_INSPECT, INSTANCE_IMAGE_READ} in tenancy image-tenancy where request.principal.type = 'nodepool'

カスタム・イメージ(宛先テナンシ)を含むテナンシで、宛先管理者は、ソース・テナンシからカスタム・イメージへのアクセスを許可するポリシー・ステートメントを作成する必要があります。例:

Define tenancy nodepool-tenancy as ocid1.tenancy.oc1...<unique_ID>
Admit any-user of tenancy nodepool-tenancy to {INSTANCE_IMAGE_INSPECT, INSTANCE_IMAGE_READ} where request.principal.type = 'nodepool'