About Access Control and Container Engine for Kubernetes


Find out about the permissions required to access clusters you've created using Container Engine for Kubernetes (OKE).

To perform operations on a Kubernetes cluster, you must have appropriate permissions to access the cluster.

For most operations on Kubernetes clusters created and managed by Container Engine for Kubernetes, Oracle Cloud Infrastructure Identity and Access Management (IAM) provides access control. A user's permissions to access clusters comes from the IAM groups (including dynamic groups) to which they belong. The permissions for a group are defined by policies. Policies define what actions members of a group can perform, and in which compartments. Users can then access clusters and perform operations based on the policies set for the groups they are members of.

IAM provides control over:

whether a user can create or delete clusters
whether a user can add, remove, or modify node pools
which Kubernetes object create/delete/view operations a user can perform on all clusters within a compartment or tenancy

See Policy Configuration for Cluster Creation and Deployment.

In addition to IAM, the Kubernetes RBAC Authorizer can enforce additional fine-grained access control for users on specific clusters via Kubernetes RBAC roles and clusterroles. A Kubernetes RBAC role is a collection of permissions. For example, a role might include read permission on pods and list permission for pods. A Kubernetes RBAC clusterrole is just like a role, but can be used anywhere in the cluster. A Kubernetes RBAC rolebinding maps a role to a user or group, granting that role's permissions to the user or group for resources in that namespace. Similarly, a Kubernetes RBAC clusterrolebinding maps a clusterrole to a user or group, granting that clusterrole's permissions to the user or group across the entire cluster.

IAM and the Kubernetes RBAC Authorizer work together to enable users who have been successfully authorized by at least one of them to complete the requested Kubernetes operation. You can use OCIDs to map Kubernetes RBAC rolebindings and clusterrolebindings to IAM users and groups (including dynamic groups).

When a user attempts to perform any operation on a cluster (except for create role and create clusterrole operations), IAM first determines whether a group (or dynamic group) to which the user belongs has the appropriate and sufficient permissions. If so, the operation succeeds. If the attempted operation also requires additional permissions granted via a Kubernetes RBAC role or clusterrole, the Kubernetes RBAC Authorizer then determines whether the user or group has been granted the appropriate Kubernetes role or clusterrole.

Typically, you’ll want to define your own Kubernetes RBAC roles and clusterroles when deploying a Kubernetes cluster to provide additional fine-grained control. When you attempt to perform a create role or create clusterrole operation, the Kubernetes RBAC Authorizer first determines whether you have sufficient Kubernetes privileges. To create a role or clusterrole, you must have been assigned an existing Kubernetes RBAC role (or clusterrole) that has at least the same or higher privileges as the new role (or clusterrole) you’re attempting to create.

By default, users are not assigned any Kubernetes RBAC roles (or clusterroles) by default. So before attempting to create a new role (or clusterrole), you must be assigned an appropriately privileged role (or clusterrole). A number of such roles and clusterroles are always created by default, including the cluster-admin clusterrole (for a full list, see Default Roles and Role Bindings in the Kubernetes documentation). The cluster-admin clusterrole essentially confers super-user privileges. A user granted the cluster-admin clusterrole can perform any operation across all namespaces in a given cluster.

Note that Oracle Cloud Infrastructure tenancy administrators already have sufficient privileges, and do not require the cluster-admin clusterrole.

Example 1: Granting the Kubernetes RBAC cluster-admin clusterrole
Example 2: Creating a Kubernetes role and rolebinding to enable a non-administrator user to read pods in a cluster
Example 3: Creating a Kubernetes role and rolebinding to enable a group to read pods in a cluster
Example 4: Creating a Kubernetes clusterrole and clusterrolebinding to enable users and groups to list secrets in a cluster
 Expand All Expandable Areas