Using RBAC Authorization [page]deterministic

referencesecurity

Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization.

RBAC authorization uses the `rbac.authorization.k8s.io` [API group](#gloss:api-group) to drive authorization decisions, allowing you to dynamically configure policies through the Kubernetes API.

To enable RBAC, start the [API server](#gloss:kube-apiserver) with the `--authorization-config` flag set to a file that includes the `RBAC` authorizer; for example:

```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AuthorizationConfiguration authorizers: ... - type: RBAC ... ```

Or, start the [API server](#gloss:kube-apiserver) with the `--authorization-mode` flag set to a comma-separated list that includes `RBAC`; for example: ```shell kube-apiserver --authorization-mode=...,RBAC --other-options --more-options ```

## API objects {#api-overview}

The RBAC API declares four kinds of Kubernetes object: _Role_, _ClusterRole_, _RoleBinding_ and _ClusterRoleBinding_. You can describe or amend the RBAC [objects](#gloss:object) using tools such as `kubectl`, just like any other Kubernetes object.

> Caution: These objects, by design, impose access restrictions. If you are making changes to a cluster as you learn, see [privilege escalation prevention and bootstrapping](#privilege-escalation-prevention-and-bootstrapping) to understand how those restrictions can prevent you making some changes.

### Role and ClusterRole

An RBAC _Role_ or _ClusterRole_ contains rules that represent a set of permissions. Permissions are purely additive (there are no "deny" rules).

A Role always sets permissions within a particular [namespace](#gloss:namespace); when you create a Role, you have to specify the namespace it belongs in.

ClusterRole, by contrast, is a non-namespaced resource. The resources have different names (Role and ClusterRole) because a Kubernetes object always has to be either namespaced or not namespaced; it can't be both.

ClusterRoles have several uses. You can use a ClusterRole to:

1. define permissions on namespaced resources and be granted access within individual namespace(s) 1. define permissions on namespaced resources and be granted access across all namespaces 1. define permissions on cluster-scoped resources

If you want to define a role within a namespace, use a Role; if you want to define a role cluster-wide, use a ClusterRole.

#### Role example

Here's an example Role in the "default" namespace that can be used to grant read access to [pods](#gloss:pod):

#### ClusterRole example

A ClusterRole can be used to grant the same permissions as a Role. Because ClusterRoles are cluster-scoped, you can also use them to grant access to:

* cluster-scoped resources (like [nodes](#gloss:node)) * non-resource endpoints (like `/healthz`) * namespaced resources (like Pods), across all namespaces

For example: you can use a ClusterRole to allow a particular user to run `kubectl get pods --all-namespaces`

Here is an example of a ClusterRole that can be used to grant read access to [secrets](#gloss:secret) in any particular namespace, or across all namespaces (depending on how it is [bound](#rolebinding-and-clusterrolebinding)):

The name of a Role or a ClusterRole object must be a valid [path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names).

### RoleBinding and ClusterRoleBinding

A role binding grants the permissions defined in a role to a user or set of users. It holds a list of *subjects* (users, groups, or service accounts), and a reference to the role being granted. A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide.

A RoleBinding may reference any Role in the same namespace. Alternatively, a RoleBinding can reference a ClusterRole and bind that ClusterRole to the namespace of the RoleBinding. If you want to bind a ClusterRole to all the …(trimmed)