Role-based access control (RBAC) is a mechanism to define the actions that user accounts can perform within your Kubernetes cluster. Enabling RBAC reduces the risk associated with credential theft and account takeover. Giving each user the minimum set of permissions they need prevents accounts from acquiring excessive privileges.
Most popular Kubernetes distributions start with a single user account that is granted superuser access to the cluster. Authenticating as this account allows you to perform any action, but can pose a significant security risk.
In this article, we’ll show you how to enable and configure the Kubernetes RBAC API so you can fine-tune user capabilities. it is common for some users to only create and list Pods, while admins can also delete items. You can configure and apply these policies through the RBAC system.
Enabling RBAC on Kubernetes
RBAC is an optional feature of Kubernetes, but most major distributions ship with it turned on by default, including those from managed cloud providers. You can check if RBAC is available on your cluster by running the following command with Kubectl:
$ kubectl api-versions | grep rbac.authorization.k8s rbac.authorization.k8s.io/v1
The command should issue
rbac.authorization.k8s.io/v1 as its output if RBAC is enabled. RBAC is turned off if the command does not produce any results. You can activate it by starting the Kubernetes API server with the
$ kube-apiserver --authorization-mode=RBAC
Consult the documentation for your Kubernetes distribution if you’re not sure how to customize the API server startup arguments.
Kubernetes RBAC objects
The Kubernetes RBAC implementation revolves around four different object types. You can manage these objects with Kubectl, similar to other Kubernetes resources like Pods, Deployments, and ConfigMaps.
- role – A role is a set of access control rules that define actions that users can perform.
- role link – A “link” is a link between a role and one or more subjects, which may be users or service accounts. The link allows subjects to perform any of the actions included in the target role.
Roles and RoleBindings are namespaced objects. They must exist within a particular namespace and control access to other objects within it. RBAC is applied to cluster-level resources, such as the nodes and namespaces themselves, using ClusterRoles other ClusterRoleBindings. These work similarly to Roles and RoleBindings, but target non-namespaced objects.
Create a service account
A Kubernetes service account is a type of user managed by the Kubernetes API. Each service account has a unique token that is used as its credentials. You I can’t add normal users via the Kubernetes API, so we’ll use a service account for this tutorial.
Use kubectl to create a new service account:
$ kubectl create serviceaccount demo
This produces a new account called
demo. Next, you need to retrieve the token that you will use to authenticate as this account. First find the name of the secret that stores the token:
$ kubectl describe serviceaccount demo Name: demo Namespace: default Labels:
Annotations: Image pull secrets: Mountable secrets: demo-token-w543b Tokens: demo-token-w543b Events:
The token for this service account is stored in the secret called
demo-token-w543b. You can retrieve the token by getting the value of the secret with this command:
$ TOKEN=$(kubectl describe secret demo-token-w543b | grep token: | awk 'print $2')
The token is now stored in the
TOKEN variables in your shell. You can use this variable to add a new Kubectl context that will allow you to authenticate as your service account:
$ kubectl config set-credentials demo --token=$TOKEN User "demo" set. $ kubectl config set-context demo --cluster=default --user=demo Context "demo" created.
You must change the value of
--cluster mark to match the name of your active kubectl cluster connection. this is usually
default or the name of your currently selected context. You can check the selected context by running
kubectl config current-context.
Switch to your new context to authenticate as your
demo service account Make a note of the name of your currently selected context first, so that you can return to your superuser account later.
$ kubectl config current-context default $ kubectl config use-context demo Switched to context "demo".
Kubectl commands will now authenticate as the
demo service account Try to retrieve the list of Pods in your cluster:
$ kubectl get pods Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo" cannot list resource "pods" in API group "" in the namespace "default"
The operation has been prohibited because the
demo the service account lacks a role that allows it to access the pods.
Add a role
Roles are created in the same way as any other Kubernetes object. Write a YAML file that defines the role and the permissions it provides. Each role contains one or more rules that allow specific actions to be performed on a set of resources. Here is a simple role that allows a user to retrieve details of existing Pods:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: demo-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"]
list verbs applied to
pods resource means you will be able to run commands like
get pod other
describe pod. Attempting to create a new Pod or delete an existing one will be prohibited because the
delete verbs are omitted from the role.
Go back to your original Kubectl context so you can add the role to your cluster using your administrative account:
$ kubectl config use-context default Switched to context "default".
Now add the role:
$ kubectl apply -f role.yaml role.rbac.authorization.k8s.io/demo-role created
Linking roles to users and service accounts
You can now associate your role with your
demo service account by creating a new RoleBinding. Create the following YAML file to define your link:
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: default name: demo-role-binding subjects: - kind: ServiceAccount name: demo apiGroup: "" roleRef: kind: Role name: demo-role apiGroup: ""
RoleBindings must include one or more subjects that identify the users and service accounts targeted by the binding. the
roleRef The field refers to the role you want to assign to each of those users.
Role and RoleBinding must exist in the same namespace. Use a ClusterRole and a ClusterRoleBinding instead for resources without namespaces.
kubectl apply to add RoleBinding to your cluster. It will enter into force immediately, granting the
demo service account the capacities declared in the
$ kubectl apply -f role-binding.yaml rolebinding.rbac.authorization.k8s.io/demo-role-binding created
Test your RBAC rule
Test your simple RBAC implementation by going back to the new Kubectl context you created for the
$ kubectl config use-context demo Switched to context "demo".
Now repeat the
get pods command from before:
$ kubectl get pods No resources found in default namespace.
This time the command has been successful. the
demo the service account can now retrieve Pod lists because it is linked to the
demo-role role You will still see a Forbidden error if you try to create a new Pod because that operation is not included in any role linked to the account:
$ kubectl run nginx --image=nginx Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo" cannot create resource "pods" in API group "" in the namespace "default"
You can resolve this by assigning the user another role that includes the
create verb for him
pods means. Alternatively, you can edit your existing role’s YAML file and apply the modified version to your cluster:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: demo-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["create", "get", "list"]
You can also add additional rules to your role to create different combinations of resource groups and allowed actions.
RBAC allows you to define the software capabilities available to individual user accounts. The Kubernetes RBAC system provides fine-grained controls to limit the types of resources accounts can access and the actions they can take.
Adopting RBAC strengthens security around your cluster and creates a less risky operating environment. However, you should still be aware of best practices to avoid introducing new problems. You should regularly audit your cluster to identify accounts with excessive privileges and clean up redundant roles. This will help avoid confusion and allow you to get a clear picture of what actions each account can take.
Effective RBAC implementations should be based on as few roles as possible, with each role having the minimum set of actions required for its specific area of functionality. Assigning too many privileges to each account negates the benefits of RBAC, so it’s worth spending time planning out the requirements for each user before you start creating roles and bindings.