--- title: "RBAC Best Practices" diataxis: reference applies_to: product: "kyverno" audience: ["platform-engineer","devsecops"] last_updated: 2026-03-25 url: https://docs.nirmata.io/docs/policy-sets/rbac_best_practices/ --- Kubernetes Role-Based-Access-Control (RBAC) is a security measure to ensure that the cluster users and workloads gets access to the required resources to execute their roles. Nirmata provides a collection of Kyverno policies that are aimed at implementing RBAC best practices. Refer to the official [Kubernetes documentation](https://kubernetes.io/docs/concepts/security/rbac-good-practices/) to learn about the practices in detail. To install all the policies for RBAC best practices, refer to the instructions provided in the [README](https://github.com/nirmata/kyverno-policies/tree/main/rbac-best-practices) guide. Click on the below profiles to dig deeper into the controls and their associated Kyverno policy. Nirmata also provides a reference to what a good resource looks like that conforms to these policies. --- ## Disable Automount SA Token ### Description A new ServiceAccount called `default` is created whenever a new Namespace is created. Pods spawned in that Namespace, unless otherwise set, will be assigned this ServiceAccount. This policy mutates any new `default` ServiceAccounts to disable auto-mounting of the token into Pods obviating the need to do so individually. ### Risks In Kubernetes, there are two key security layers: authentication and authorization (authz). Authentication ensures that the pod or user is who they claim to be, while authorization determines what actions they're allowed to perform. When a pod is created, it automatically mounts a service account token, which allows it to interact with the Kubernetes API server for authentication purposes. However, by default, the pod doesn't have permission (via authorization) to do much with that access. The problem arises when an attacker gains control of a pod. Even though the attacker might not have initial permissions (due to the security of the authz layer), if they manage to bypass authorization, they can exploit the service account token to escalate privileges and perform unauthorized actions across the cluster. For example, an attacker could perform API requests like creating or deleting pods. ### Kyverno Policy Refer to the Nirmata curated policies - [disable-automount-sa-token](https://github.com/nirmata/kyverno-policies/blob/main/rbac-best-practices/disable-automount-sa-token/disable-automount-sa-token.yaml). #### Resource Example Below is an example of a `ServiceAccount` resource enforcing this policy where `automountServiceAccountToken` is set to `false`. ````bash apiVersion: v1 kind: ServiceAccount automountServiceAccountToken: false metadata: name: default namespace: disable-satokenmount-ns ```` --- ## Restrict Automount SA Token ### Description Kubernetes automatically mounts `ServiceAccount` credentials in each Pod. The `ServiceAccount` may be assigned roles allowing Pods to access API resources. Blocking this ability is an extension of the least privilege best practice and should be followed if Pods do not need to speak to the API server to function. This policy ensures that mounting of these ServiceAccount tokens is blocked. ### Risks In Kubernetes, there are two key security layers: authentication and authorization (authz). Authentication ensures that the pod or user is who they claim to be, while authorization determines what actions they're allowed to perform. When a pod is created, it automatically mounts a service account token, which allows it to interact with the Kubernetes API server for authentication purposes. However, by default, the pod doesn't have permission (via authorization) to do much with that access. The problem arises when an attacker gains control of a pod. Even though the attacker might not have initial permissions (due to the security of the authz layer), if they manage to bypass authorization, they can exploit the service account token to escalate privileges and perform unauthorized actions across the cluster. For example, an attacker could perform API requests like creating or deleting pods. ### Kyverno Policy Refer to the Nirmata curated policies - [restrict-automount-sa-token](https://github.com/nirmata/kyverno-policies/blob/main/rbac-best-practices/restrict-automount-sa-token/restrict-automount-sa-token.yaml). #### Resource Example Below is an example of a `Deployment` resource that has `automountServiceAccountToken` set to `false`. ```bash apiVersion: apps/v1 kind: Deployment metadata: labels: app: busybox name: gooddeployment01 spec: replicas: 1 selector: matchLabels: app: busybox strategy: {} template: metadata: labels: app: busybox spec: automountServiceAccountToken: false containers: - name: busybox image: busybox:1.35 ``` Below is another example of a `CronJob` resource enforcing this policy. ```bash apiVersion: batch/v1 kind: CronJob metadata: labels: name: goodcronjob01 spec: schedule: "* * * * *" jobTemplate: spec: template: spec: containers: - name: busybox image: busybox:1.35 automountServiceAccountToken: false restartPolicy: OnFailure ```text --- ## Restrict Binding System Groups ### Description Certain system groups exist in Kubernetes which grant permissions that are used for certain system-level functions yet typically never appropriate for other users. This policy prevents creating bindings for `system:masters` group. ### Risks `system:masters` group is a built-in group in Kubernetes that provides unrestricted level of access to the Kubernetes API server. Users who are members of this group have full cluster-admin rights to the cluster. Even if every cluster role and role is deleted from the cluster, users who are members of this group still retain full access to the cluster. `system:masters` is a break-glass, super user group that bypasses the authorization layer (for example RBAC) and is not intended for general cluster administration. ### Kyverno Policy Refer to the Nirmata curated policies - [restrict-binding-system-groups](https://github.com/nirmata/kyverno-policies/blob/main/rbac-best-practices/restrict-binding-system-groups/restrict-binding-system-groups.yaml). #### Resource Example Below is an example of a `ClusterRoleBinding` resource that does not bind to the `system:masters` role. ```bash apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: goodcrb02 subjects: - kind: ServiceAccount namespace: foo name: foo-reader roleRef: kind: ClusterRole name: manager apiGroup: rbac.authorization.k8s.io ``` Below is an example of a `RoleBinding` resource that does not bind to the `system:masters` group. ```bash apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: goodrb01 subjects: - kind: User name: foo apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: foo-bar apiGroup: rbac.authorization.k8s.io ```text --- ## Restrict ClusterRole Nodesproxy ### Description A ClusterRole with nodes/proxy resource access allows a user to perform anything the kubelet API allows. It also allows users to bypass the API server and talk directly to the kubelet potentially circumventing audits and admission controllers. Refer to the [official Aquasec blog](https://blog.aquasec.com/privilege-escalation-kubernetes-rbac) for more info. This policy prevents the creation of a ClusterRole if it contains the nodes/proxy resource. ### Risks Risks associated with a ClusterRole containing the `nodes/proxy` resource: - `Privilege Escalation`: A user with permissions on the `nodes/proxy` subresource in a cluster has full permissions against the kubelet API on any node by proxying requests through the API server, and can execute commands in any pod. This may represent privileges beyond those expected by the cluster administrator. Refer to this [issue](https://github.com/kubernetes/kubernetes/issues/119640) for more information. ### Kyverno Policy Refer to the Nirmata curated policies - [restrict-clusterrole-nodesproxy](https://github.com/nirmata/kyverno-policies/blob/main/rbac-best-practices/restrict-clusterrole-nodesproxy/restrict-clusterrole-nodesproxy.yaml). #### Resource Example Below are examples of two `ClusterRole` resources that do not have `nodes/proxy` resource. ```bash apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: goodcr01 rules: - apiGroups: [""] resources: ["pods", "namespaces"] verbs: ["get", "watch", "list"] - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "watch", "list"] ``` ```bash apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: goodcr02 rules: - apiGroups: [""] resources: ["nodes"] verbs: ["get", "watch", "list"] ```text --- ## Restrict Escalation Verbs Roles ### Description The verbs `impersonate`, `bind`, and `escalate` may all potentially lead to privilege escalation and should be tightly controlled. This policy prevents use of these verbs in Role or ClusterRole resources. ### Risks Risks associated with `bind`, `escalate`, and `impersonate` verbs: Bind Verb The `bind` verb poses a risk because it allows users to create or modify role bindings, granting themselves or others access to permissions that they do not already have. If an unauthorized user gains this ability, they can escalate their privileges by binding roles with broad permissions, and allow themselves to have unauthorized access to sensitive resources. Escalate Verb A user with `escalate` privileges can modify the roles or cluster roles that are assigned to them and increase the level of privileges they have. An attacker can exploit this to perform unintended actions in the cluster. Impersonate Verb The `impersonate` verb allows a user to act as another user, group, or service account. This capability is sensitive, as it can lead to security breaches. If an attacker can impersonate a user with elevated privileges, they can execute actions on behalf of that user and negatively impact the cluster. ### Kyverno Policy Refer to the Nirmata curated policies - [restrict-escalation-verbs-roles](https://github.com/nirmata/kyverno-policies/blob/main/rbac-best-practices/restrict-escalation-verbs-roles/restrict-escalation-verbs-roles.yaml). #### Resource Example Below is an example of a `ClusterRole` resource that does not include any of the escalation verbs. ```bash apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: goodcr01 rules: - apiGroups: [""] resources: ["pods", "namespaces"] verbs: ["get", "watch", "list"] - apiGroups: ["rbac.authorization.k8s.io", "apps"] resources: ["deployments", "roles"] verbs: ["get", "watch", "list"] - apiGroups: ["rbac.authorization.k8s.io"] resources: ["clusterroles"] verbs: ["update", "watch", "list"] ``` Below is an example of a `Role` resource that does not include any of the escalation verbs. ```bash apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: goodrole01 rules: - apiGroups: [""] resources: ["pods", "namespaces"] verbs: ["get", "watch", "list"] - apiGroups: ["rbac.authorization.k8s.io", "apps"] resources: ["deployments", "roles"] verbs: ["get", "watch", "list"] - apiGroups: ["rbac.authorization.k8s.io"] resources: ["clusterroles"] verbs: ["update", "watch", "list"] ```text --- ## Restrict Wildcard Resources ### Description Wildcards (`*`) in resources grant access to all of the resources referenced by the given API group and does not follow the principal of least privilege. As much as possible, avoid such open resources unless scoped to perhaps a custom API group. This policy blocks any Role or ClusterRole that contains a wildcard entry in the resources list found in any rule. ### Risks Risks associated with using wildcard (`*`) in `resources`: - `Privilege Escalation`: If a user or service account with wildcard permissions is compromised, an attacker can gain unrestricted access to all resources in the namespace (or across the cluster if it's a `ClusterRole`). This can cause the attacker to perform critical actions such as creating, modifying, or deleting resources based on the `verbs` set in the `Role` or `ClusterRole`, thereby escalating privileges and causing widespread damage. ### Kyverno Policy Refer to the Nirmata curated policies - [restrict-wildcard-resources](https://github.com/nirmata/kyverno-policies/blob/main/rbac-best-practices/restrict-wildcard-resources/restrict-wildcard-resources.yaml). #### Resource Example Below is an example of a `ClusterRole` resource that does not include any wildcards for resources. ```bash apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: goodcr01 rules: - apiGroups: [""] resources: ["pods", "namespaces"] verbs: ["get", "watch", "list"] - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "watch", "list"] ``` Below is an example of a `Role` resource that does not include any wildcards for resources. ```bash apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: goodcr03 rules: - apiGroups: ["batch"] resources: ["secrets"] verbs: ["create", "update", "patch"] ```text