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

Container Engine for Kubernetes (OKE)を使用する前に、作成するIAMポリシーを確認します。

テナンシが作成されると、テナンシに対して管理者グループが自動的に作成されます。管理者グループのメンバーであるユーザーは、テナンシのリソースに対して任意の操作を実行できます。Container Engine for Kubernetesを操作するすべてのユーザーがすでに管理者グループのメンバーである場合、他のポリシーを作成する必要はありません。

ただし、管理者グループのメンバーでないユーザーがContainer Engine for Kubernetesを使用できるようにするには、テナンシまたは個々のコンパートメントのリソースに対して操作を実行するためにユーザーが属するグループを有効化するポリシーを作成する必要があります。一部のポリシーは必須であり、一部はオプションです。グループに必要なポリシーの作成およびグループに対する1つ以上の追加ポリシーの作成を参照してください。

また、次の場合に追加のポリシーを作成する必要があります:

仮想ノードおよび仮想ノード・プールを含むクラスタを作成および使用します。仮想ノードを設定および使用するためのポリシーの作成を参照してください。
Vaultサービスの独自のマスター暗号化キーを使用して、ブート・ボリュームおよびブロック・ボリュームのデータを暗号化します。ブート・ボリューム、ブロック・ボリュームまたはファイル・システム(あるいはその両方)を暗号化するためにユーザー管理暗号化キーにアクセスするポリシーの作成を参照してください。

1つのテナンシ内のユーザーのグループが他のテナンシのクラスタ関連リソースにアクセスする場合は、アクセスおよび共有できるリソースを明示的に記述する特別なクロステナンシ・ポリシー・ステートメントを作成する必要があります。テナンシ間でのクラスタ関連リソースへのアクセスを参照してください。

IAMで管理されている前述のポリシーに加えて、Kubernetes RBAC Authorizerを使用し、Kubernetes RBACロールやclusterroleを介して、特定のクラスタのユーザーに対して、追加のファイングレイン・アクセス制御を実施することもできます。アクセス制御およびContainer Engine for Kubernetesについてを参照してください。

グループに必要なポリシーの作成

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

ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「アイデンティティ」で、「ポリシー」をクリックします。表示しているコンパートメント内のポリシーのリストが表示されます。
左側のリストから、テナンシのルート・コンパートメントまたはクラスタ関連リソースを含む個々のコンパートメントを選択します。
「ポリシーの作成」をクリックします。
次を入力します:
- 名前: コンパートメント内で一意のポリシーの名前(たとえば、acme-dev-team-oke-required-policy)。テナンシのルート・コンパートメントにポリシーを作成する場合、テナンシ内のすべてのポリシー間で名前が一意である必要があります。これは後で変更できません。機密情報の入力は避けてください。
- 説明: わかりやすい説明。これは必要に応じて後で変更できます。
- ステートメント: ユーザーがContainer Engine for 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ポリシー・ステートメントが必要です。
- タグ: リソースの作成権限がある場合は、そのリソースにフリーフォーム・タグを適用する権限もあります。定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。タグ付けの詳細は、リソース・タグを参照してください。タグを適用するかどうかがわからない場合は、このオプションをスキップするか、管理者に問い合せてください。タグは後から適用できます。
「作成」をクリックします。

グループに対する1つ以上の追加ポリシーの作成

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

ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「アイデンティティ」で、「ポリシー」をクリックします。表示しているコンパートメント内のポリシーのリストが表示されます。
左側のリストから、テナンシのルート・コンパートメントまたはクラスタ関連リソースを含む個々のコンパートメントを選択します。
「ポリシーの作成」をクリックします。
次を入力します:
- 名前: コンパートメント内で一意のポリシーの名前(たとえば、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グループのユーザーがボールト・サービスでマスター暗号化キーおよびボールトを選択できるようにするには:
```
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>
```
    詳細は、容量予約を使用した管理対象ノードのプロビジョニングを参照してください
- タグ: リソースの作成権限がある場合は、そのリソースにフリーフォーム・タグを適用する権限もあります。定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。タグ付けの詳細は、リソース・タグを参照してください。タグを適用するかどうかがわからない場合は、このオプションをスキップするか、管理者に問い合せてください。タグは後から適用できます。
「作成」をクリックします。

仮想ノードを設定および使用するためのポリシーの作成

仮想ノードおよび仮想ノード・プールを使用するクラスタを作成および使用するには、常に少なくとも1つのIAMポリシーを設定する必要があります。これは、テナンシ管理者と非管理者ユーザーの両方がすべての状況で必要になります。管理者以外のユーザーが仮想ノードを使用できるようにするには、追加のポリシーも設定する必要があります。要約すると、ポリシーは次のようになります。

Container Engine for Kubernetesサービスを承認して、テナンシ内のVCNのサブネットに接続されたVNICを使用して、仮想ノードがContainer Engine for Kubernetesサービス・テナンシにコンテナ・インスタンスを作成できるようにします。
管理者以外のユーザーに必要な権限を付与します。

入力するポリシー・ステートメントの詳細は、仮想ノードを使用するために必要なIAMポリシーを参照してください。

ブート・ボリューム、ブロック・ボリュームまたはファイル・システムを暗号化するためのユーザー管理の暗号化キーにアクセスするポリシーの作成

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

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

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

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

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

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

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>'

ここでは:

<group-name>は、自分が属するグループです。
<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 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>'}