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 Policy for Container Engine for Kubernetes (Required).

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. However, if you want to enable users that are not members of the Administrators group to use Container Engine for Kubernetes, you must write policies to enable the groups to which those users do belong to perform operations on cluster-related resources in the tenancy. See Create One or More Policies for Groups (Optional).

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 Policy for Container Engine for Kubernetes (Required)

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 One or More Policies for Groups (Optional)

To enable users that are not members of the Administrators group to use Container Engine for Kubernetes, create policies to enable the groups to which those users do belong to perform operations on cluster-related resources in the tenancy 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, acme-dev-team-oke-policy). 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 tenancy. For example:

      • To enable users in the acme-dev-team group to perform any operation on cluster-related resources, enter a policy statement like Allow group acme-dev-team to manage cluster-family in tenancy. This 'catch-all' policy effectively makes all users administrators insofar as cluster-related resources are concerned.

      • To enable users in the acme-dev-team group to create or modify clusters using the Console, or 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 tenancy
        • the SUBNET_READ and SUBNET_CREATE permissions. Enter a policy statement like Allow group acme-dev-team to manage subnets in tenancy
        • the COMPARTMENT_INSPECT permission. Enter a policy statement like Allow group acme-dev-team to inspect compartments in tenancy
        • the INTERNET_GATEWAY_CREATE permission. Enter a policy statement like Allow group acme-dev-team to manage internet-gateways in tenancy
        • the NAT_GATEWAY_CREATE permission. Enter a policy statement like Allow group acme-dev-team to manage nat-gateways in tenancy
        • the ROUTE_TABLE_UPDATE permission. Enter a policy statement like Allow group acme-dev-team to manage route-tables in tenancy
        • the SECURITY_LIST_CREATE permission. Enter a policy statement like Allow group acme-dev-team to manage security-lists in tenancy
      • 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 tenancy.
      • 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 tenancy.
      • 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 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.