Oracle Cloud Infrastructure Documentation

Policy Configuration for Cluster Creation and Deployment

Before you can use Container Engine for Kubernetes to create and deploy clusters in the regions in a tenancy, the tenancy's root compartment must include a policy to allow Container Engine for Kubernetes to perform operations in the tenancy. See Create Required Policy for Container Engine for Kubernetes.

When a tenancy is created, an Administrators group is automatically created for the tenancy. 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 Container Engine for Kubernetes are already members of the Administrators group, there's no need to create additional policies (aside from the policy to allow Container Engine for Kubernetes to perform operations in the tenancy). However, if you want to enable users that are not members of the Administrators group to use Container Engine for Kubernetes, 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 and Create One or More Additional Policies for Groups.

Note that in addition to 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 via Kubernetes RBAC roles and clusterroles. See About Access Control and Container Engine for Kubernetes.

Create Required Policy for Container Engine for Kubernetes

To create and manage clusters in your tenancy, Container Engine for Kubernetes must have access to all resources in the tenancy. To give Container Engine for Kubernetes the necessary access, create a policy for the service as follows:

  1. In the Console, open the navigation menu. Under Governance and Administration, go to Identity and click Policies. A list of the policies in the compartment you're viewing is displayed.
  2. Select the tenancy's root compartment from the list on the left.
  3. Click Create Policy.
  4. Enter the following:

    • Name: A unique name for the policy (for example, oke-service). The name must be unique across all policies in your tenancy. You cannot change this later. Avoid entering confidential information.
    • Description: A friendly description. You can change this later if you want to. Avoid entering confidential information.
    • Policy Versioning: Select Keep Policy Current if you'd like the policy to stay current with any future changes to the service's definitions of verbs and resources. Or if you'd prefer to limit access according to the definitions that were current on a specific date, select Use Version Date and enter that date in YYYY-MM-DD format. For more information, see Policy Language Version.
    • Statement: The following policy statement:

      Allow service OKE to manage all-resources in tenancy
    • Tags: Optionally, you can apply tags. If you have permissions to create a resource, you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your administrator.
  5. Click Create.

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:

  1. In the Console, open the navigation menu. Under Governance and Administration, go to Identity and click Policies. A list of the policies in the compartment you're viewing is displayed.
  2. Select the tenancy's root compartment or an individual compartment containing cluster-related resources from the list on the left.
  3. Click Create Policy.
  4. Enter the following:

    • Name: A name for the policy (for example, acme-dev-team-oke-required-policy) that is unique within the compartment. If you are creating the policy in the tenancy's root compartment, the name must be unique across all policies in your tenancy. You cannot change this later. Avoid entering confidential information.
    • Description: A friendly description. You can change this later if you want to. Avoid entering confidential information.
    • Policy Versioning: Select Keep Policy Current if you'd like the policy to stay current with any future changes to the service's definitions of verbs and resources. Or if you'd prefer to limit access according to the definitions that were current on a specific date, select Use Version Date and enter that date in YYYY-MM-DD format. For more information, see Policy Language Version.
    • Statement: The following required policy statements to enable users to use Container Engine for Kubernetes 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 read virtual-network-family in <location>

      • Allow group <group-name> to use vnics in <location>
      • Allow group <group-name> to inspect compartments 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 either tenancy (if you are creating the policy in the tenancy's root compartment) or compartment <compartment-name> (if you are creating the policy in an individual compartment).

    • Tags: Optionally, you can apply tags. If you have permissions to create a resource, you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your administrator.
  5. Click Create.

Create One or More Additional Policies for Groups

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

  1. In the Console, open the navigation menu. Under Governance and Administration, go to Identity and click Policies. A list of the policies in the compartment you're viewing is displayed.
  2. Select the tenancy's root compartment or an individual compartment containing cluster-related resources from the list on the left.
  3. Click Create Policy.
  4. Enter the following:

    • Name: A name for the policy (for example, acme-dev-team-oke-additional-policy) that is unique within the compartment. If you are creating the policy in the tenancy's root compartment, the name must be unique across all policies in your tenancy. You cannot change this later. Avoid entering confidential information.
    • Description: A friendly description. You can change this later if you want to. Avoid entering confidential information.
    • Policy Versioning: Select Keep Policy Current if you'd like the policy to stay current with any future changes to the service's definitions of verbs and resources. Or if you'd prefer to limit access according to the definitions that were current on a specific date, select Use Version Date and enter that date in YYYY-MM-DD format. For more information, see Policy Language Version.
    • 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 either tenancy (if you are creating the policy in the tenancy's root compartment) or compartment <compartment-name> (if you are creating the policy in an individual compartment):

      • To enable users in the acme-dev-team group to automatically create and configure associated new network resources when creating new 'quick clusters', policies must also grant the group:

        • the VCN_READ and VCN_CREATE permissions. Enter a policy statement like Allow group acme-dev-team to manage vcns in <location>
        • the SUBNET_READ and SUBNET_CREATE permissions. Enter a policy statement like Allow group acme-dev-team to manage subnets in <location>
        • the INTERNET_GATEWAY_CREATE permission. Enter a policy statement like Allow group acme-dev-team to manage internet-gateways in <location>
        • the NAT_GATEWAY_CREATE permission. Enter a policy statement like Allow group acme-dev-team to manage nat-gateways in <location>
        • the ROUTE_TABLE_UPDATE permission. Enter a policy statement like Allow group acme-dev-team to manage route-tables in <location>
        • the SECURITY_LIST_CREATE permission. Enter a policy statement like Allow group acme-dev-team to manage security-lists in <location>
      • To enable users in the acme-dev-team-cluster-viewers group to simply list the clusters, enter a policy statement like Allow group acme-dev-team-cluster-viewers to inspect clusters in <location>.
      • To enable users in the acme-dev-team-pool-admins group to list, create, update, and delete node pools, enter a policy statement like Allow group acme-dev-team-pool-admins to use cluster-node-pools in <location>.
      • To enable users in the acme-dev-team-auditors group to see details of operations performed on clusters, enter a policy statement like Allow group acme-dev-team-auditors to read cluster-work-requests in <location>.
      • To enable users in the acme-dev-team-sgw group to create a service gateway to enable worker nodes to access other resources in the same region without exposing data to the public internet, enter a policy statement like Allow group acme-dev-team-sgw to manage service-gateways in <location>.
    • Tags: Optionally, you can apply tags. If you have permissions to create a resource, you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your administrator.
  5. Click Create.