Role Based Access Control Good Practices

KubernetesRBAC is a key security controlto ensure that cluster users and workloads have only the access to resources required toexecute their roles. It is important to ensure that, when designing permissions for clusterusers, the cluster administrator understands the areas where privilege escalation could occur,to reduce the risk of excessive access leading to security incidents.

The good practices laid out here should be read in conjunction with the generalRBAC documentation.

General good practice

Least privilege

Ideally, minimal RBAC rights should be assigned to users and service accounts. Only permissionsexplicitly required for their operation should be used. While each cluster will be different,some general rules that can be applied are :

• Assign permissions at the namespace level where possible. Use RoleBindings as opposed toClusterRoleBindings to give users rights only within a specific namespace.
• Avoid providing wildcard permissions when possible, especially to all resources.As Kubernetes is an extensible system, providing wildcard access gives rightsnot just to all object types that currently exist in the cluster, but also to all object typeswhich are created in the future.
• Administrators should not usecluster-admin accounts except where specifically needed.Providing a low privileged account withimpersonation rightscan avoid accidental modification of cluster resources.
• Avoid adding users to thesystem:masters group. Any user who is a member of this groupbypasses all RBAC rights checks and will always have unrestricted superuser access, which cannot berevoked by removing RoleBindings or ClusterRoleBindings. As an aside, if a cluster isusing an authorization webhook, membership of this group also bypasses that webhook (requestsfrom users who are members of that group are never sent to the webhook)

Minimize distribution of privileged tokens

Ideally, pods shouldn't be assigned service accounts that have been granted powerful permissions(for example, any of the rights listed underprivilege escalation risks).In cases where a workload requires powerful permissions, consider the following practices:

• Limit the number of nodes running powerful pods. Ensure that any DaemonSets you runare necessary and are run with least privilege to limit the blast radius of container escapes.
• Avoid running powerful pods alongside untrusted or publicly-exposed ones. Consider usingTaints and Toleration,NodeAffinity, orPodAntiAffinityto ensure pods don't run alongside untrusted or less-trusted Pods. Pay special attention tosituations where less-trustworthy Pods are not meeting theRestricted Pod Security Standard.

Hardening

Kubernetes defaults to providing access which may not be required in every cluster. Reviewingthe RBAC rights provided by default can provide opportunities for security hardening.In general, changes should not be made to rights provided tosystem: accounts some optionsto harden cluster rights exist:

• Review bindings for thesystem:unauthenticated group and remove them where possible, as this givesaccess to anyone who can contact the API server at a network level.
• Avoid the default auto-mounting of service account tokens by settingautomountServiceAccountToken: false. For more details, seeusing default service account token.Setting this value for a Pod will overwrite the service account setting, workloadswhich require service account tokens can still mount them.

Periodic review

It is vital to periodically review the Kubernetes RBAC settings for redundant entries andpossible privilege escalations.If an attacker is able to create a user account with the same name as a deleted user,they can automatically inherit all the rights of the deleted user, especially therights assigned to that user.

Kubernetes RBAC - privilege escalation risks

Within Kubernetes RBAC there are a number of privileges which, if granted, can allow a user or a service accountto escalate their privileges in the cluster or affect systems outside the cluster.

This section is intended to provide visibility of the areas where cluster operatorsshould take care, to ensure that they do not inadvertently allow for more access to clusters than intended.

Listing secrets

It is generally clear that allowingget access on Secrets will allow a user to read their contents.It is also important to note thatlist andwatch access also effectively allow for users to reveal the Secret contents.For example, when a List response is returned (for example, viakubectl get secrets -A -o yaml), the responseincludes the contents of all Secrets.

Workload creation

Permission to create workloads (either Pods, orworkload resources that manage Pods) in a namespaceimplicitly grants access to many other resources in that namespace, such as Secrets, ConfigMaps, andPersistentVolumes that can be mounted in Pods. Additionally, since Pods can run as anyServiceAccount, granting permissionto create workloads also implicitly grants the API access levels of any service account in thatnamespace.

Users who can run privileged Pods can use that access to gain node access and potentially tofurther elevate their privileges. Where you do not fully trust a user or other principalwith the ability to create suitably secure and isolated Pods, you should enforce either theBaseline orRestricted Pod Security Standard.You can usePod Security admissionor other (third party) mechanisms to implement that enforcement.

For these reasons, namespaces should be used to separate resources requiring different levels oftrust or tenancy. It is still considered best practice to followleast privilegeprinciples and assign the minimum set of permissions, but boundaries within a namespace should beconsidered weak.

Persistent volume creation

If someone - or some application - is allowed to create arbitrary PersistentVolumes, that accessincludes the creation ofhostPath volumes, which then means that a Pod would get accessto the underlying host filesystem(s) on the associated node. Granting that ability is a security risk.

There are many ways a container with unrestricted access to the host filesystem can escalate privileges, includingreading data from other containers, and abusing the credentials of system services, such as Kubelet.

You should only allow access to create PersistentVolume objects for:

• Users (cluster operators) that need this access for their work, and who you trust.
• The Kubernetes control plane components which creates PersistentVolumes based on PersistentVolumeClaimsthat are configured for automatic provisioning.This is usually setup by the Kubernetes provider or by the operator when installing a CSI driver.

Where access to persistent storage is required trusted administrators should createPersistentVolumes, and constrained users should use PersistentVolumeClaims to access that storage.

Access toproxy subresource of Nodes

Users with access to the proxy sub-resource of node objects have rights to the Kubelet API,which allows for command execution on every pod on the node(s) to which they have rights.This access bypasses audit logging and admission control, so care should be taken beforegranting rights to this resource.

Escalate verb

Generally, the RBAC system prevents users from creating clusterroles with more rights than the user possesses.The exception to this is theescalate verb. As noted in theRBAC documentation,users with this right can effectively escalate their privileges.

Bind verb

Similar to theescalate verb, granting users this right allows for the bypass of Kubernetesin-built protections against privilege escalation, allowing users to create bindings toroles with rights they do not already have.

Impersonate verb

This verb allows users to impersonate and gain the rights of other users in the cluster.Care should be taken when granting it, to ensure that excessive permissions cannot be gainedvia one of the impersonated accounts.

CSRs and certificate issuing

The CSR API allows for users withcreate rights to CSRs andupdate rights oncertificatesigningrequests/approvalwhere the signer iskubernetes.io/kube-apiserver-client to create new client certificateswhich allow users to authenticate to the cluster. Those client certificates can have arbitrarynames including duplicates of Kubernetes system components. This will effectively allow for privilege escalation.

Token request

Users withcreate rights onserviceaccounts/token can create TokenRequests to issuetokens for existing service accounts.

Control admission webhooks

Users with control overvalidatingwebhookconfigurations ormutatingwebhookconfigurationscan control webhooks that can read any object admitted to the cluster, and in the case ofmutating webhooks, also mutate admitted objects.

Namespace modification

Users who can performpatch operations on Namespace objects (through a namespaced RoleBinding to a Role with that access) can modifylabels on that namespace. In clusters where Pod Security Admission is used, this may allow a user to configure the namespacefor a more permissive policy than intended by the administrators.For clusters where NetworkPolicy is used, users may be set labels that indirectly allowaccess to services that an administrator did not intend to allow.

Kubernetes RBAC - denial of service risks

Object creation denial-of-service

Users who have rights to create objects in a cluster may be able to create sufficient largeobjects to create a denial of service condition either based on the size or number of objects, as discussed inetcd used by Kubernetes is vulnerable to OOM attack. This may bespecifically relevant in multi-tenant clusters if semi-trusted or untrusted usersare allowed limited access to a system.

One option for mitigation of this issue would be to useresource quotasto limit the quantity of objects which can be created.

What's next

• To learn more about RBAC, see theRBAC documentation.