Policy Configuration for Cluster Creation and Deployment

Find out about the IAM policies to create before using Kubernetes Engine (OKE).

When a tenancy is created, an Administrators group is automatically created for the tenancy in OCI Identity and Access Management (IAM). Users that are members of the Administrators group can perform any operation on resources in the tenancy. If all the users that will be working with Kubernetes Engine are already members of the Administrators group, there's no need to create other policies.

However, if you want to enable users that are not members of the Administrators group to use Kubernetes Engine, you must create policies to enable the groups to which those users do belong to perform operations on resources in the tenancy or in individual compartments. Some policies are required, some are optional. See Create Required Policy for Groups andCreate One or More Additional Policies for Groups.

You also have to create additional policies if you want to:

Create and use clusters with virtual nodes and virtual node pools. SeeCreate Policy to Set Up and Use Virtual Nodes.
Encrypt data in boot volumes and block volumes using your own master encryption keys from theVault service. SeeCreate Policy to Access User-Managed Encryption Keys for Encrypting Boot Volumes, Block Volumes, and/or File Systems.

If you want groups of users in one tenancy to access cluster-related resources in other tenancies, you have to create special cross-tenancy policy statements that explicitly state the resources that can be accessed and shared. SeeAccessing Cluster-Related Resources Across Tenancies.

As well as the above policies managed by IAM, you can also use the Kubernetes RBAC Authorizer to enforce additional fine-grained access control for users on specific clusters using Kubernetes RBAC roles and clusterroles (seeAbout Access Control and Kubernetes Engine (OKE). These Kubernetes RBAC rules control what authenticated users and service accounts can do within the cluster, such as deploying workloads or accessing secrets, using the Kubernetes API.

Note that an OCI IAM policy that refers to a network source (such asallow any-user to use clusters in tenancy where request.networkSource.name='corpnet') cannot be used to access the Kubernetes API (for example, when using kubectl). For more information about network sources, seeIntroduction to Network Sources.

Create Required Policy for Groups

To create, update, and delete clusters and node pools, users that are not members of the Administrators group must have permissions to work with cluster-related resources. To give users the necessary access, you must create a policy with a number of required policy statements for the groups to which those users do belong:

Open thenavigation menu and selectIdentity & Security. UnderIdentity, selectPolicies. A list of the policies in the compartment you're viewing is displayed.

Select the tenancy's root compartment or an individual compartment containing cluster-related resources from theCompartment filter.

SelectCreate Policy.

Enter the following:
- Statement: The following required policy statements to enable users to use Kubernetes Engine to create, update, and delete clusters and node pools:
```
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>
```
```
Allow group <group-name> to manage volume-family in <location>
```
  The following required policy statement to enable users to perform any operation on cluster-related resources (this 'catch-all' policy effectively makes all users administrators insofar as cluster-related resources are concerned):
```
Allow group <group-name> to manage cluster-family in <location>
```
  In the above policy statements, replace<location> with eithertenancy (if you are creating the policy in the tenancy's root compartment) orcompartment <compartment-name> (if you are creating the policy in an individual compartment).
  Note
  
  Note that depending on the type of cluster, some required policy statements might not be necessary:
  To work with "VCN-native" clusters (where the Kubernetes API endpoint is fully integrated with your VCN), theuse private-ips is always required. However, theuse public-ips policy statement is only necessary if the clusters' public IP address option is selected. For more information about VCN-native clusters, seeKubernetes Cluster Control Plane and Kubernetes API.
  To work with clusters where the public Kubernetes API endpoint is in an Oracle-managed tenancy, theuse vnics,use private-ips, anduse public-ips policy statements are unnecessary.
  Note that if a group is not in the default identity domain, prefix the group name with the identity domain name, in the formatgroup '<identity-domain-name>'/'group-name'. You can also specify a group using its OCID, in the formatgroup id <group-ocid>.
- Tags:If you have permissions to create a resource, then you also have permissions to applyfree-form tags to that resource. To apply adefined tag, you must have permissions to use the tagnamespace. For more information about tagging, see Resource Tags. If you're not sure whether to apply tags, skip this option or ask an administrator. You can apply tags later.
SelectCreate.

Create One or More Additional Policies for Groups

To enable users that are not members of the Administrators group to use Kubernetes Engine, create additional policies to enable the groups to which those users do belong to perform operations on cluster-related resources as follows:

Open thenavigation menu and selectIdentity & Security. UnderIdentity, selectPolicies. A list of the policies in the compartment you're viewing is displayed.

Select the tenancy's root compartment or an individual compartment containing cluster-related resources from theCompartment filter.

SelectCreate Policy.

Enter the following:
- Statement: A suitable policy statement to allow existing groups to perform operations on cluster-related resources. In the example policy statements below, replace<location> with eithertenancy (if you are creating the policy in the tenancy's root compartment) orcompartment <compartment-name> (if you are creating the policy in an individual compartment):
  - To enable users in the acme-dev-team group to access clusters using Cloud Shell, enter a policy statement like:
    Allow group acme-dev-team to use cloud-shell in <location>
    Note that to access clusters using Cloud Shell, you'll also need to set up the kubeconfig file appropriately (seeSetting Up Cloud Shell Access to Clusters). For more information about Cloud Shell, see Cloud Shell.
  - To enable users in the acme-dev-team group to select master encryption keys and vaults in the Vault service when creating and modifying clusters using the Console:
```
Allow group acme-dev-team to read vaults in <location>
```
```
Allow group acme-dev-team to read keys in <location>
```
  - To enable users in the acme-dev-team group to use capacity reservations:
```
Allow group acme-dev-team to use compute-capacity-reservations in <location>
```
    For more information, seeUsing Capacity Reservations to Provision Managed Nodes
  - To enable users in the acme-dev-team group to use metrics (for example, to observe the condition of nodes in a Kubernetes cluster):
```
Allow group acme-dev-team to read metrics in <location>
```
    For more information, seeKubernetes Engine (OKE) Metrics.
  Note
  
  Note that if a group is not in the default identity domain, prefix the group name with the identity domain name, in the formatgroup '<identity-domain-name>'/'group-name'. You can also specify a group using its OCID, in the formatgroup id <group-ocid>.
- Tags:If you have permissions to create a resource, then you also have permissions to applyfree-form tags to that resource. To apply adefined tag, you must have permissions to use the tagnamespace. For more information about tagging, seeResource Tags. If you're not sure whether to apply tags, skip this option or ask an administrator. You can apply tags later.
SelectCreate.

Create Policy to Set Up and Use Virtual Nodes

Administrator users do not require additional permissions to create and use clusters with virtual nodes and virtual node pools.

To enable non-administrator users to use virtual nodes, you must set up an additional policy to give such users the required permissions. For more information about the policy statements to enter, see Required IAM Policies for Using Virtual Nodes.

Create Policy to Access User-Managed Encryption Keys for Encrypting Boot Volumes, Block Volumes, and/or File Systems

To specify a particular user-managed master encryption key from the Vault service to encrypt data in boot volumes, block volumes, and/or file systems, you have to create a policy to allow access to that master encryption key. For more information about specifying user-managed encryption keys:

for boot volumes, seeUsing the Console to create a Cluster with Explicitly Defined Settings in the 'Custom Create' workflow andModifying Node Pool and Worker Node Properties as appropriate.
for block volumes, seeEncrypting Data At Rest and Data In Transit with the Block Volume Service
for file systems, seeEncrypting Data At Rest and Data In Transit with the File Storage Service

Note that before you can create the policy, you have to know the master encryption key's OCID (seeManaging Keys).

To create a policy to allow access to a user-managed master encryption key:

Open thenavigation menu and selectIdentity & Security. UnderIdentity, selectPolicies. A list of the policies in the compartment you're viewing is displayed.
Select the tenancy's root compartment or an individual compartment containing cluster-related resources from theCompartment filter.
SelectCreate Policy, follow the instructions inTo create a policy, and give the policy a name (for example,acme-oke-keys-policy).

For boot volumes: To use a master encryption key from the Vault service to encrypt data in boot volumes, enter the following policy statements to grant access to the master encryption key:

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

where:

<group-name> is a group to which you belong. Note that if a group is not in the default identity domain, prefix the group name with the identity domain name, in the formatgroup '<identity-domain-name>'/'group-name'. You can also specify a group using its OCID, in the formatgroup id <group-ocid>.
<compartment-name> is the name of the compartment containing the master encryption key.
<key-OCID> is the OCID of the master encryption key in Vault.

For example:

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

Note

After August 15, 2024, create theAllow any-user... policy statement as shown, namely:

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

Note that before August 15, 2024, you had to define the followingAllow service oke... policy statement:

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

If such anAllow service oke... policy statement already exists, keep this existing policy statement, and create the newAllow any-user... policy statement in addition to the existing policy statement.

For block volumes: To use a master encryption key from the Vault service to encrypt data in block volumes, enter policy statements to grant access to the master encryption key in the format:

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