Container Engine's Role-Based Access Control (RBAC) lets you exercise fine-grained control over how users access the Kubernetes API resources running on your container cluster. You can use RBAC to dynamically configure permissions for your cluster's users and define the kinds of resources with which they can interact.
You can create RBAC permissions that apply to your entire cluster, or to specific namespaces within your cluster. Cluster-wide permissions are useful for limiting certain users' access to specific API resources (such as security policies or Secrets). Namespace-specific permissions are useful if, for example, you have multiple groups of users operating within their own respective namespaces. RBAC can help you ensure that users only have access to cluster resources within their own namespace.
Interaction with Identity and Access Management
Container Engine also uses Identity and Access Management (IAM) to control access to your container cluster. However, IAM works on a per-project basis—that is, users require IAM-level permissions to access any cluster in a given Cloud Platform project.
RBAC permissions provide finer-grained control over access to resources within each cluster. As such, IAM and RBAC can work in concert, and a user must have sufficient permissions at either level to work with resources in your cluster.
Prerequisites for using Role-Based Access Control
To ensure your RBAC permissions take effect, you must
create or update your cluster with
By default, a Container Engine cluster has multiple authorizers enabled: IAM, RBAC and a legacy authorization system. In Kubernetes, authorizers interact by granting a permission if any authorizer grants the permission. The legacy authorizer in Container Engine grants broad, statically defined permissions. To ensure that RBAC limits permissions correctly, you must disable the legacy authorizer.
When creating a new cluster that uses RBAC, you must
with the option
To update an existing cluster to use RBAC, you must update
with the option
--no-enable-legacy-authorization to disable the legacy
Once the cluster has the legacy authorizer disabled, you must grant your user the ability to create authorization roles by running the following Kubernetes command:
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin [--user=<user-name>]
Setting up Role-Based Access Control
You define your RBAC permissions by creating objects
rbac.authorization.k8s.io API group in your cluster. You can create
the objects using the
kubectl command-line interface, or programmatically.
You'll need to create two kinds of objects:
ClusterRoleobject that defines what resource types and operations are allowed for a set of users.
ClusterRoleBindingthat associates the
ClusterRole) with one or more specific users.
RBAC permissions are purely additive--there are no "deny" rules. When structuring your RBAC permissions, you should think in terms of "granting" users access to cluster resources.
Defining Permissions in a
You define permissions within a Kubernetes
ClusterRole API object. A
Role grants access to resources within a single namespace, while a
ClusterRole grants access to resources in the entire cluster.
ClusterRole) object, you define the permissions as a
rules determine the namespace, resource type, and
allowable operations for that role. For example, you can create a
grants read access (operations such as
list) for all Pod
resources in a given namespace.
ClusterRole permissions apply across the entire cluster, you can use
them to control access to different kinds of resources than you can with a
Role. These include:
- Cluster-scoped resources such as Nodes
- Non-resource Endpoints such as
- Namespaced resources across all namespaces (for example, all Pods across the entire cluster, regardless of namespace)
Assigning Permissions to Users with
Once you've created the
ClusterRole), you must create a
ClusterRoleBinding) object to grant the permissions in the
ClusterRole) to a set of users. The users can be individual users,
or Kubernetes service accounts.
By default, Kubernetes service accounts have full permissions on the Kubernetes API. To ensure that your RBAC permissions take effect for your Kubernetes service account, you must [create your cluster](/container-engine/docs/clusters/operations) with the option `--no-enable-legacy-authorization`.
ClusterRoleBinding) contains a list of the users, and a
reference to the
ClusterRole) being granted to those users.
API Usage and Examples
For complete information on using the Kubernetes API to create the necessary
ClusterRoleBinding objects for
RBAC, see Using Role-Based Access Control Authorization
in the Kubernetes documentation.