テナンシをまたがったクラスタ関連リソースへのアクセス
1つのテナンシが他のテナンシのクラスタ関連リソースにアクセスできるようにするために必要なIAMポリシーについて学習します。
1つのテナンシが他のテナンシのリソースにアクセスする場合は、クロステナンシ・ポリシーを作成する必要があります。
ポリシーを初めて使用する場合は、ポリシーの開始および次を参照してください:
クロステナンシ・ポリシー
組織は、独自のテナントを持つ別の組織とクラスタ関連リソースを共有する場合があります。これは、会社内の別のビジネス・ユニット、会社の顧客、会社にサービスを提供する会社などの場合があります。このような場合、クラスタ作成およびデプロイメントのポリシー構成で説明されている必要なユーザー・ポリシーおよびサービス・ポリシーに加えて、クロステナンシ・ポリシーが必要です。
承認、許可および定義ステートメント
2つのテナンシ間でリソースにアクセスして共有するには、両方のテナンシの管理者は、アクセスと共有が可能なリソースを明示的に示す特別なポリシー・ステートメントを作成する必要があります。これらの特別なステートメントは、Define、Endorseおよび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'