クラスタの作成とデプロイメントのためのポリシー構成

クラスタおよびノード・プールを作成、更新および削除するには、管理者グループのメンバーでないユーザーが、クラスタ関連リソースを操作するための権限を持っている必要があります。ユーザーに必要なアクセス権を付与するには、ユーザーが属するグループに必要な数のポリシー・ステートメントを含むポリシーを作成する必要があります:

1. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」を選択します。「アイデンティティ」で、「ポリシー」を選択します。表示しているコンパートメント内のポリシーのリストが表示されます。
2. 左側のリストから、テナンシのルート・コンパートメントまたはクラスタ関連リソースを含む個々のコンパートメントを選択します。
3. 「ポリシーの作成」をクリックします。

4. 次を入力します:

   • 名前: コンパートメント内で一意のポリシーの名前(たとえば、acme-dev-team-oke-required-policy)。テナンシのルート・コンパートメントにポリシーを作成する場合、テナンシ内のすべてのポリシー間で名前が一意である必要があります。これは後で変更できません。機密情報の入力は避けてください。
   • 説明: わかりやすい説明。これは必要に応じて後で変更できます。

   • ステートメント:ユーザーがKubernetesエンジンを使用してクラスタおよびノード・プールを作成、更新および削除できるようにするために必要な次のポリシー・ステートメント:

     Allow group <group-name> to manage instance-family in <location>

     Allow group <group-name> to use subnets in <location>

     Allow group <group-name> to manage virtual-network-family in <location>

     Allow group <group-name> to inspect compartments in <location>

     Allow group <group-name> to use vnics in <location>

     Allow group <group-name> to use network-security-groups  in <location>

     Allow group <group-name> to use private-ips  in <location>

     Allow group <group-name> to manage public-ips  in <location>

     クラスタ関連リソースに対する任意の操作をユーザーが実行できるようにするために必要な次のポリシー・ステートメント(この'catch-all'ポリシーは、クラスタ関連リソースに関するかぎり、すべてのユーザーを効果的に管理者にします):

     Allow group <group-name> to manage cluster-family in <location>

     前述のポリシー・ステートメントで、<location>を、tenancy (テナンシのルート・コンパートメントにポリシーを作成している場合)またはcompartment <compartment-name> (個々のコンパートメントにポリシーを作成している場合)に置換します。

     ノート
     
     ノート: クラスタのタイプによっては、一部の必須ポリシー・ステートメントが必要ない可能性があることに注意してください:

     • 「VCNネイティブ」クラスタ(Kubernetes APIエンドポイントがVCNと完全に統合されている)を操作するには、use private-ipsが常に必要です。ただし、use public-ipsポリシー・ステートメントは、クラスタのパブリックIPアドレス・オプションが選択されている場合にのみ必要です。VCNネイティブ・クラスタの詳細は、Kubernetesクラスタ・コントロール・プレーンおよびKubernetes APIを参照してください。
     • パブリックKubernetes APIエンドポイントがOracle管理テナンシ内にあるクラスタを使用するには、use vnics、use private-ipsおよびuse public-ipsポリシー・ステートメントは必要ありません。

     グループがデフォルトのアイデンティティ・ドメインにない場合は、group '<identity-domain-name>'/'group-name'の形式で、グループ名の前にアイデンティティ・ドメイン名を追加します。group id <group-ocid>の形式で、そのOCIDを使用してグループを指定することもできます。

   • タグ: リソースの作成権限がある場合は、そのリソースにフリーフォーム・タグを適用する権限もあります。定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。タグ付けの詳細は、リソース・タグを参照してください。タグを適用するかどうかがわからない場合は、このオプションをスキップするか、管理者に連絡してください。タグは後で適用できます。
5. 「作成」をクリックします。

管理者グループのメンバーでないユーザーがKubernetesエンジンを使用できるようにするには、次のように、クラスタ関連のリソースに対して操作を実行するためにユーザーが属するグループを有効化する追加ポリシーを作成します:

1. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」を選択します。「アイデンティティ」で、「ポリシー」を選択します。表示しているコンパートメント内のポリシーのリストが表示されます。
2. 左側のリストから、テナンシのルート・コンパートメントまたはクラスタ関連リソースを含む個々のコンパートメントを選択します。
3. 「ポリシーの作成」をクリックします。

4. 次を入力します:

   • 名前: コンパートメント内で一意のポリシーの名前(たとえば、acme-dev-team-oke-additional-policy)。テナンシのルート・コンパートメントにポリシーを作成する場合、テナンシ内のすべてのポリシー間で名前が一意である必要があります。これは後で変更できません。機密情報の入力は避けてください。
   • 説明: わかりやすい説明。これは必要に応じて後で変更できます。

   • ステートメント: 既存のグループがクラスタ関連リソースで操作を実行できるようにするための適切なポリシー・ステートメント。後述のポリシー・ステートメントの例で、<location>を、tenancy (テナンシのルート・コンパートメントにポリシーを作成している場合)またはcompartment <compartment-name> (個々のコンパートメントにポリシーを作成している場合)に置換します:

     • acme-dev-teamグループのユーザーがクイック作成ワークフローで新しいクラスタを作成するときに、関連付けられた新しいネットワーク・リソースを自動的に作成および構成できるようにするには、ポリシーで次のものもグループに付与する必要があります:

       • VCN_READおよびVCN_CREATE権限。次のようなポリシー・ステートメントを入力します:

         Allow group acme-dev-team to manage vcns in <location>

       • SUBNET_READおよびSUBNET_CREATE権限。次のようなポリシー・ステートメントを入力します:

         Allow group acme-dev-team to manage subnets in <location>

       • INTERNET_GATEWAY_CREATE権限。次のようなポリシー・ステートメントを入力します:

         Allow group acme-dev-team to manage internet-gateways in <location>

       • NAT_GATEWAY_CREATE権限。次のようなポリシー・ステートメントを入力します:

         Allow group acme-dev-team to manage nat-gateways in <location>

       • ROUTE_TABLE_UPDATE権限。次のようなポリシー・ステートメントを入力します:

         Allow group acme-dev-team to manage route-tables in <location>

       • SECURITY_LIST_CREATE権限。次のようなポリシー・ステートメントを入力します:

         Allow group acme-dev-team to manage security-lists in <location>

     • acme-dev-team-cluster-viewersグループのユーザーがクラスタを単純にリストできるようにするには、次のようなポリシー・ステートメントを入力します:

       Allow group acme-dev-team-cluster-viewers to inspect clusters in <location>

     • acme-dev-team-pool-adminsグループのユーザーがノード・プールをリスト、作成、更新および削除できるようにするには、次のようなポリシー・ステートメントを入力します:

       Allow group acme-dev-team-pool-admins to use cluster-node-pools in <location>

     • acme-dev-team-auditorsグループのユーザーがクラスタで実行された操作の詳細を表示できるようにするには、次のようなポリシー・ステートメントを入力します:

       Allow group acme-dev-team-auditors to read cluster-work-requests in <location>

     • acme-dev-team-sgwグループのユーザーが、サービス・ゲートウェイを作成して、ワーカー・ノードがデータをパブリック・インターネットに公開することなく同じリージョンの他のリソースにアクセスできるようにするには、次のようなポリシー・ステートメントを入力します:

       Allow group acme-dev-team-sgw to manage service-gateways in <location>

     • acme-dev-teamグループのユーザーがクラウド・シェルを使用してクラスタにアクセスできるようにするには、次のようなポリシー・ステートメントを入力します:

       Allow group acme-dev-team to use cloud-shell in <location>

       クラウド・シェルを使用してクラスタにアクセスするには、kubeconfigファイルも適切に設定する必要があります(クラスタへのクラウド・シェル・アクセスの設定を参照)。クラウド・シェルの詳細は、クラウド・シェルを参照してください。

     • コンソールを使用してクラスタを作成および変更するときに、acme-dev-teamグループのユーザーがVaultサービスでマスター暗号化キーおよびボールトを選択できるようにするには:

       Allow group acme-dev-team to read vaults in <location>

       Allow group acme-dev-team to read keys in <location>

     • acme-dev-teamグループのユーザーが容量予約を使用できるようにするには:

       Allow group acme-dev-team to use compute-capacity-reservations in <location>

       詳細は、容量予約を使用した管理対象ノードのプロビジョニングを参照してください

     • acme-dev-teamグループのユーザーがメトリックを使用できるようにするには(たとえば、Kubernetesクラスタ内のノードの状態を監視するには):

       Allow group acme-dev-team to read metrics in <location>

       詳細は、Kubernetesエンジン(OKE)のメトリックを参照してください。

     ノート
     
     

     グループがデフォルトのアイデンティティ・ドメインにない場合は、group '<identity-domain-name>'/'group-name'の形式で、グループ名の前にアイデンティティ・ドメイン名を追加します。group id <group-ocid>の形式で、そのOCIDを使用してグループを指定することもできます。

   • タグ: リソースの作成権限がある場合は、そのリソースにフリーフォーム・タグを適用する権限もあります。定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。タグ付けの詳細は、リソース・タグを参照してください。タグを適用するかどうかがわからない場合は、このオプションをスキップするか、管理者に連絡してください。タグは後で適用できます。
5. 「作成」をクリックします。

管理者ユーザーは、仮想ノードおよび仮想ノード・プールでクラスタを作成および使用するための追加の権限を必要としません。

管理者以外のユーザーが仮想ノードを使用できるようにするには、追加のポリシーを設定して、そのようなユーザーに必要な権限を付与する必要があります。入力するポリシー・ステートメントの詳細は、仮想ノードを使用するための必要なIAMポリシーを参照してください。

Vaultサービスから特定のユーザー管理マスター暗号化キーを指定して、ブート・ボリューム、ブロック・ボリュームまたはファイル・システム(あるいはその両方)のデータを暗号化するには、そのマスター暗号化キーへのアクセスを許可するポリシーを作成する必要があります。ユーザー管理暗号化キーの指定の詳細は、次を参照してください。

• ブート・ボリュームについては、コンソールを使用したカスタム作成ワークフローでの明示的定義設定によるクラスタの作成およびノード・プールおよびワーカー・ノードのプロパティの変更を参照してください。
• ブロック・ボリュームについては、ブロック・ボリューム・サービスを使用した停止中のデータおよび転送中のデータの暗号化を参照してください
• ファイル・システムについては、ファイル・ストレージ・サービスを使用した保存中のデータおよび転送中のデータの暗号化を参照してください

ポリシーを作成する前に、マスター暗号化キーのOCIDを知っておく必要があります(キーの管理を参照)。

ユーザー管理のマスター暗号化キーへのアクセスを許可するポリシーを作成するには:

1. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」を選択します。「アイデンティティ」で、「ポリシー」を選択します。表示しているコンパートメント内のポリシーのリストが表示されます。
2. 表示しているコンパートメント内のポリシーのリストが表示されます。
3. 左側のリストから、テナンシのルート・コンパートメントまたはクラスタ関連リソースを含む個々のコンパートメントを選択します。
4. 「ポリシーの作成」をクリックし、ポリシーを作成するにはの手順に従って、ポリシーに名前を付けます(たとえば、acme-oke-keys-policy)。

5. ブート・ボリュームの場合: Vaultサービスのマスター暗号化キーを使用してブート・ボリュームのデータを暗号化するには、次のポリシー・ステートメントを入力してマスター暗号化キーへのアクセス権を付与します:

   Allow group <group-name> to read keys in compartment <compartment-name> where target.key.id = '<key_OCID>'

   
   Allow service oke to use key-delegates in compartment <compartment-name> where target.key.id = '<key_OCID>'

   
   Allow service blockstorage to use keys in compartment <compartment-name> where target.key.id = '<key_OCID>'

   
   Allow any-user to use key-delegates in compartment <compartment-name> where ALL {request.principal.type='nodepool', target.key.id = '<key_OCID>'}

   ここでは:

   • <group-name>は、自分が属するグループです。グループがデフォルトのアイデンティティ・ドメインにない場合は、group '<identity-domain-name>'/'group-name'の形式で、グループ名の前にアイデンティティ・ドメイン名を追加します。group id <group-ocid>の形式で、そのOCIDを使用してグループを指定することもできます。
   • <compartment-name>は、マスター暗号化キーを含むコンパートメントの名前です。
   • <key-OCID>は、ボールトにおけるマスター暗号化キーのOCIDです。

   例:

   Allow group acme-dev-team to read keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
   Allow service oke to use key-delegates in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
   Allow service blockstorage to use keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
   Allow any-user to use key-delegates in compartment acme-kms-key-compartment where ALL {request.principal.type='nodepool', target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'}

   ノート
   
   

   2024年8月15日以降、次のようにAllow any-user...ポリシー・ステートメントを作成します:

   Allow any-user to use key-delegates in <compartment-name> where ALL {request.principal.type='nodepool', target.key.id = '<key_OCID>'}

   2024年8月15日より前に、次のAllow service oke...ポリシー・ステートメントを定義する必要がありました。

   Allow service oke to use key-delegates in compartment <compartment-name> where target.key.id = '<key_OCID>' 

   そのようなAllow service oke...ポリシー・ステートメントがすでに存在する場合は、この既存のポリシー・ステートメントを保持し、既存のポリシー・ステートメントに加えて新しいAllow any-user...ポリシー・ステートメントを作成します。

6. ブロック・ボリュームの場合: Vaultサービスのマスター暗号化キーを使用してブロック・ボリュームのデータを暗号化するには、ポリシー・ステートメントを入力して、マスター暗号化キーへのアクセス権を次の形式で付与します:

   Allow service blockstorage to use keys in compartment <compartment-name> where target.key.id = '<key-ocid>'

   
   Allow any-user to use key-delegates in compartment <compartment-name> where ALL {request.principal.type = 'cluster', target.key.id = '<key-ocid>'}

   ここでは:

   • <compartment-name>は、マスター暗号化キーを含むコンパートメントの名前です。
   • <key-OCID>は、ボールトにおけるマスター暗号化キーのOCIDです。

   例:

   Allow service blockstorage to use keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
   Allow any-user to use key-delegates in compartment acme-kms-key-compartment where ALL {request.principal.type = 'cluster', target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'}

7. ファイル・システムの場合: Vaultサービスのマスター暗号化キーを使用してファイル・システムのデータを暗号化するには、ポリシー・ステートメントを入力してマスター暗号化キーへのアクセス権を次の形式で付与します:

   Allow dynamic-group <dynamic-group-name> to use keys in compartment <key-compartment-name>

   
   Allow any-user to use key-delegates in compartment <compartment-name> where ALL {request.principal.type = 'cluster', target.key.id = '<key_OCID>'}

   ここでは:

   • <dynamic-group-name>は、コンパートメント内のファイル・システムの動的グループの名前です。

     動的グループのルールの例を次に示します。

     ALL { resource.type='filesystem', resource.compartment.id = '<file_system_compartment_OCID>' }

     動的グループがデフォルトのアイデンティティ・ドメインにない場合は、dynamic-group '<identity-domain-name>'/'<dynamic-group-name>'の形式で、動的グループ名の前にアイデンティティ・ドメイン名を追加します。dynamic-group id <dynamic-group-ocid>の形式で、そのOCIDを使用して動的グループを指定することもできます。

   • <compartment-name>は、マスター暗号化キーを含むコンパートメントの名前です。
   • <key_OCID>は、Vaultのマスター暗号化キーのOCIDです。

   例:

   Allow dynamic-group FssFileSystems to use keys in compartment acme-kms-key-compartment
   Allow any-user to use key-delegates in compartment acme-kms-key-compartment where ALL {request.principal.type = 'cluster', target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'}

8. 「作成」をクリックします。