{ "id": "9b4fbe60-7cd0-48b9-b263-e712e931afe3", "created_at": "2026-04-06T00:06:28.288377Z", "updated_at": "2026-04-10T13:13:04.357798Z", "deleted_at": null, "sha1_hash": "423fc7b3af0777ace506f595cde7404cbe01f252", "title": "Role Based Access Control Good Practices", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 70756, "plain_text": "Role Based Access Control Good Practices\r\nArchived: 2026-04-05 21:38:08 UTC\r\nPrinciples and practices for good RBAC design for cluster operators.\r\nKubernetes RBAC is a key security control to ensure that cluster users and workloads have only the access to\r\nresources required to execute their roles. It is important to ensure that, when designing permissions for cluster\r\nusers, the cluster administrator understands the areas where privilege escalation could occur, to reduce the risk of\r\nexcessive access leading to security incidents.\r\nThe good practices laid out here should be read in conjunction with the general RBAC documentation.\r\nGeneral good practice\r\nLeast privilege\r\nIdeally, minimal RBAC rights should be assigned to users and service accounts. Only permissions explicitly\r\nrequired for their operation should be used. While each cluster will be different, some general rules that can be\r\napplied are :\r\nAssign permissions at the namespace level where possible. Use RoleBindings as opposed to\r\nClusterRoleBindings to give users rights only within a specific namespace.\r\nAvoid providing wildcard permissions when possible, especially to all resources. As Kubernetes is an\r\nextensible system, providing wildcard access gives rights not just to all object types that currently exist in\r\nthe cluster, but also to all object types which are created in the future.\r\nAdministrators should not use cluster-admin accounts except where specifically needed. Providing a\r\nlow privileged account with impersonation rights can avoid accidental modification of cluster resources.\r\nAvoid adding users to the system:masters group. Any user who is a member of this group bypasses all\r\nRBAC rights checks and will always have unrestricted superuser access, which cannot be revoked by\r\nremoving RoleBindings or ClusterRoleBindings. As an aside, if a cluster is using an authorization\r\nwebhook, membership of this group also bypasses that webhook (requests from users who are members of\r\nthat group are never sent to the webhook)\r\nMinimize distribution of privileged tokens\r\nIdeally, pods shouldn't be assigned service accounts that have been granted powerful permissions (for example,\r\nany of the rights listed under privilege escalation risks). In cases where a workload requires powerful permissions,\r\nconsider the following practices:\r\nLimit the number of nodes running powerful pods. Ensure that any DaemonSets you run are necessary and\r\nare run with least privilege to limit the blast radius of container escapes.\r\nhttps://kubernetes.io/docs/concepts/security/rbac-good-practices/\r\nPage 1 of 5\n\nAvoid running powerful pods alongside untrusted or publicly-exposed ones. Consider using Taints and\r\nToleration, NodeAffinity, or PodAntiAffinity to ensure pods don't run alongside untrusted or less-trusted\r\nPods. Pay special attention to situations where less-trustworthy Pods are not meeting the Restricted Pod\r\nSecurity Standard.\r\nHardening\r\nKubernetes defaults to providing access which may not be required in every cluster. Reviewing the RBAC rights\r\nprovided by default can provide opportunities for security hardening. In general, changes should not be made to\r\nrights provided to system: accounts some options to harden cluster rights exist:\r\nReview bindings for the system:unauthenticated group and remove them where possible, as this gives\r\naccess to anyone who can contact the API server at a network level.\r\nAvoid the default auto-mounting of service account tokens by setting automountServiceAccountToken:\r\nfalse . For more details, see using default service account token. Setting this value for a Pod will\r\noverwrite the service account setting, workloads which require service account tokens can still mount\r\nthem.\r\nPeriodic review\r\nIt is vital to periodically review the Kubernetes RBAC settings for redundant entries and possible privilege\r\nescalations. If an attacker is able to create a user account with the same name as a deleted user, they can\r\nautomatically inherit all the rights of the deleted user, especially the rights assigned to that user.\r\nKubernetes RBAC - privilege escalation risks\r\nWithin Kubernetes RBAC there are a number of privileges which, if granted, can allow a user or a service account\r\nto escalate their privileges in the cluster or affect systems outside the cluster.\r\nThis section is intended to provide visibility of the areas where cluster operators should take care, to ensure that\r\nthey do not inadvertently allow for more access to clusters than intended.\r\nListing secrets\r\nIt is generally clear that allowing get access on Secrets will allow a user to read their contents. It is also\r\nimportant to note that list and watch access also effectively allow for users to reveal the Secret contents. For\r\nexample, when a List response is returned (for example, via kubectl get secrets -A -o yaml ), the response\r\nincludes the contents of all Secrets.\r\nWorkload creation\r\nPermission to create workloads (either Pods, or workload resources that manage Pods) in a namespace implicitly\r\ngrants access to many other resources in that namespace, such as Secrets, ConfigMaps, and PersistentVolumes that\r\ncan be mounted in Pods. Additionally, since Pods can run as any ServiceAccount, granting permission to create\r\nworkloads also implicitly grants the API access levels of any service account in that namespace.\r\nhttps://kubernetes.io/docs/concepts/security/rbac-good-practices/\r\nPage 2 of 5\n\nUsers who can run privileged Pods can use that access to gain node access and potentially to further elevate their\r\nprivileges. Where you do not fully trust a user or other principal with the ability to create suitably secure and\r\nisolated Pods, you should enforce either the Baseline or Restricted Pod Security Standard. You can use Pod\r\nSecurity admission or other (third party) mechanisms to implement that enforcement.\r\nFor these reasons, namespaces should be used to separate resources requiring different levels of trust or tenancy. It\r\nis still considered best practice to follow least privilege principles and assign the minimum set of permissions, but\r\nboundaries within a namespace should be considered weak.\r\nPersistent volume creation\r\nIf someone - or some application - is allowed to create arbitrary PersistentVolumes, that access includes the\r\ncreation of hostPath volumes, which then means that a Pod would get access to the underlying host\r\nfilesystem(s) on the associated node. Granting that ability is a security risk.\r\nThere are many ways a container with unrestricted access to the host filesystem can escalate privileges, including\r\nreading data from other containers, and abusing the credentials of system services, such as Kubelet.\r\nYou should only allow access to create PersistentVolume objects for:\r\nUsers (cluster operators) that need this access for their work, and who you trust.\r\nThe Kubernetes control plane components which creates PersistentVolumes based on\r\nPersistentVolumeClaims that are configured for automatic provisioning. This is usually setup by the\r\nKubernetes provider or by the operator when installing a CSI driver.\r\nWhere access to persistent storage is required trusted administrators should create PersistentVolumes, and\r\nconstrained users should use PersistentVolumeClaims to access that storage.\r\nAccess to proxy subresource of Nodes\r\nUsers with access to the nodes/proxy sub-resource have rights to the Kubelet API, which allows for command\r\nexecution on every pod on the node(s) to which they have rights. This access bypasses audit logging and\r\nadmission control, so care should be taken before granting any rights to this resource. These APIs can be exercised\r\nvia websocket HTTP GET requests, which only requires authorization of the get verb. This means that get\r\npermission on nodes/proxy is not a read-only permission.\r\nSee Kubelet authentication/authorization for more information.\r\nEscalate verb\r\nGenerally, the RBAC system prevents users from creating clusterroles with more rights than the user possesses.\r\nThe exception to this is the escalate verb. As noted in the RBAC documentation, users with this right can\r\neffectively escalate their privileges.\r\nBind verb\r\nhttps://kubernetes.io/docs/concepts/security/rbac-good-practices/\r\nPage 3 of 5\n\nSimilar to the escalate verb, granting users this right allows for the bypass of Kubernetes in-built protections\r\nagainst privilege escalation, allowing users to create bindings to roles with rights they do not already have.\r\nImpersonate verb\r\nThis verb allows users to impersonate and gain the rights of other users in the cluster. Care should be taken when\r\ngranting it, to ensure that excessive permissions cannot be gained via one of the impersonated accounts.\r\nCSRs and certificate issuing\r\nThe CSR API allows for users with create rights to CSRs and update rights on\r\ncertificatesigningrequests/approval where the signer is kubernetes.io/kube-apiserver-client to create\r\nnew client certificates which allow users to authenticate to the cluster. Those client certificates can have arbitrary\r\nnames including duplicates of Kubernetes system components. This will effectively allow for privilege escalation.\r\nToken request\r\nUsers with create rights on serviceaccounts/token can create TokenRequests to issue tokens for existing\r\nservice accounts.\r\nControl admission webhooks\r\nUsers with control over validatingwebhookconfigurations or mutatingwebhookconfigurations can control\r\nwebhooks that can read any object admitted to the cluster, and in the case of mutating webhooks, also mutate\r\nadmitted objects.\r\nNamespace modification\r\nUsers who can perform patch operations on Namespace objects (through a namespaced RoleBinding to a Role\r\nwith that access) can modify labels on that namespace. In clusters where Pod Security Admission is used, this may\r\nallow a user to configure the namespace for a more permissive policy than intended by the administrators. For\r\nclusters where NetworkPolicy is used, users may be set labels that indirectly allow access to services that an\r\nadministrator did not intend to allow.\r\nKubernetes RBAC - denial of service risks\r\nObject creation denial-of-service\r\nUsers who have rights to create objects in a cluster may be able to create sufficient large objects to create a denial\r\nof service condition either based on the size or number of objects, as discussed in etcd used by Kubernetes is\r\nvulnerable to OOM attack. This may be specifically relevant in multi-tenant clusters if semi-trusted or untrusted\r\nusers are allowed limited access to a system.\r\nOne option for mitigation of this issue would be to use resource quotas to limit the quantity of objects which can\r\nbe created.\r\nhttps://kubernetes.io/docs/concepts/security/rbac-good-practices/\r\nPage 4 of 5\n\nWhat's next\r\nTo learn more about RBAC, see the RBAC documentation.\r\nSource: https://kubernetes.io/docs/concepts/security/rbac-good-practices/\r\nhttps://kubernetes.io/docs/concepts/security/rbac-good-practices/\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://kubernetes.io/docs/concepts/security/rbac-good-practices/" ], "report_names": [ "rbac-good-practices" ], "threat_actors": [ { "id": "2864e40a-f233-4618-ac61-b03760a41cbb", "created_at": "2023-12-01T02:02:34.272108Z", "updated_at": "2026-04-10T02:00:04.97558Z", "deleted_at": null, "main_name": "WildCard", "aliases": [], "source_name": "ETDA:WildCard", "tools": [ "RustDown", "SysJoker" ], "source_id": "ETDA", "reports": null }, { "id": "256a6a2d-e8a2-4497-b399-628a7fad4b3e", "created_at": "2023-11-30T02:00:07.299845Z", "updated_at": "2026-04-10T02:00:03.484788Z", "deleted_at": null, "main_name": "WildCard", "aliases": [], "source_name": "MISPGALAXY:WildCard", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775433988, "ts_updated_at": 1775826784, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/423fc7b3af0777ace506f595cde7404cbe01f252.pdf", "text": "https://archive.orkl.eu/423fc7b3af0777ace506f595cde7404cbe01f252.txt", "img": "https://archive.orkl.eu/423fc7b3af0777ace506f595cde7404cbe01f252.jpg" } }