diff --git a/content/en/docs/concepts/security/rbac-good-practices.md b/content/en/docs/concepts/security/rbac-good-practices.md new file mode 100644 index 0000000000..2434b13f75 --- /dev/null +++ b/content/en/docs/concepts/security/rbac-good-practices.md @@ -0,0 +1,175 @@ +--- +reviewers: +title: Role Based Access Control Good Practices +description: > + Principles and practices for good RBAC design for cluster operators. +content_type: concept +--- + + + +Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}} is a key security control +to ensure that cluster users and workloads have only the access to resources required to +execute their roles. It is important to ensure that, when designing permissions for cluster +users, the cluster administrator understands the areas where privilge 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 general [RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update). + + + +## General good practice + +### Least privilege + +Ideally minimal RBAC rights should be assigned to users and service accounts. Only permissions +explicitly required for their operation should be used. Whilst 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 to + ClusterRoleBindings 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 rights + not just to all object types presently in the cluster, but also to all future object types + which are created in the future. + - Administrators should not use `cluster-admin` accounts except where specifically needed. + Providing a low privileged account with [impersonation rights](/docs/reference/access-authn-authz/authentication/#user-impersonation) + can avoid accidental modification of cluster resources. + - Avoid adding users to the `system:masters` group. Any user who is a member of this group + bypasses all RBAC rights checks and will always have unrestricted superuser access, which cannot be + revoked by removing Role Bindings or Cluster Role Bindings. As an aside, if a cluster is + using an authorization webhook, membership of this group also bypasses that webhook (requests + from 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 granted powerful permissions (listed [here](#Kubernetes-RBAC---Privilege-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 run + are 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 using + [Taints and Toleration](/docs/concepts/scheduling-eviction/taint-and-toleration/), [NodeAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity), or [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) to ensure + pods don't run alongside untrusted or less-trusted Pods. Pay especial attention to + situations where less-trustworthy Pods are not meeting the **Restricted** Pod Security Standard. + +### Hardening + +Kubernetes defaults to providing access which may not be required in every cluster. Reviewing +the RBAC rights provided by default can provide opportunities for security hardening. +In general, changes should not be made to rights provided to `system:` accounts some options +to harden cluster rights exist: + +- Review bindings for the `system:unauthenticated` group and remove where possible, as this gives + access to anyone who can contact the API server at a network level. +- Avoid the default auto-mounting of service account tokens by setting + `automountServiceAccountToken: false`. For more details, see + [using default service account token](/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server). + Setting this value for a Pod will overwrite the service account setting, workloads + which require service account tokens can still mount them. + +### Periodic review + +It is vital to periodically review the Kubernetes RBAC settings for redundant entries and +possible 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 the +rights assigned to that user. + +## Kubernetes RBAC - privilege escalation risks {#privilege-escalation-risks} + +Within Kubernetes RBAC there are a number of privileges which, if granted, can allow a user or a service account +to escalate their privileges in the cluster or affect systems outside the cluster. + +This section is intended to provide visibility of the areas where cluster operators +should take care, to ensure that they do not inadvertantly allow for more access to clusters than intended. + +### Listing secrets + +It is generally clear that allowing `get` access on Secrets will allow a user to read their contents. +It is also important to note that `list` and `watch` access also effectively allow for users to reveal the Secret contents. +For example, when a List response is returned (for example, via `kubectl get secrets -A -o yaml`), the response +includes the contents of all Secrets. + +### Workload creation + +Users who are able to create workloads (either Pods, or +[workload resources](/docs/concepts/workloads/controllers/) that manage Pods) will +be able to gain access to the underlying node unless restrictions based on the Kubernetes +[Pod Security Standards](/docs/concepts/security/pod-security-standards/) are in place. + +Users who can run privileged Pods can use that access to gain node access and potentially to +further elevate their privileges. Where you do not fully trust a user or other principal +with the ability to create suitably secure and isolated Pods, you should enforce either the +**Baseline** or **Restricted** Pod Security Standard. +You can use [Pod Security admission](/docs/concepts/security/pod-security-admission/) +or other (third party) mechanisms to implement that enforcement. + +You can also use the deprecated [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) mechanism +to restrict users' abilities to create privileged Pods (N.B. PodSecurityPolicy is scheduled for removal +in version 1.25). + +Creating a workload in a namespace also grants indirect access to Secrets in that namespace. +Creating a pod in kube-system or a similarly privileged namespace can grant a user access to +Secrets they would not have through RBAC directly. + +### Persistent volume creation + +As noted in the [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems) documentation, access to create PersistentVolumes can allow for escalation of access to the underlying host. Where access to persistent storage is required trusted administrators should create +PersistentVolumes, and constrained users should use PersistentVolumeClaims to access that storage. + +### Access to `proxy` 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) which they have rights to. +This access bypasses audit logging and admission control, so care should be taken before +granting rights to this resource. + +### Escalate verb + +Generally the RBAC system prevents users from creating clusterroles with more rights than +they possess. The exception to this is the `escalate` verb. As noted in the [RBAC documentation](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update), +users with this right can effectively escalate their privileges. + +### Bind verb + +Similar to the `escalate` verb, granting users this right allows for bypass of Kubernetes +in-built protections against privilege escalation, allowing users to create bindings to +roles 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 gained +via one of the impersonated accounts. + +### CSRs and certificate issuing + +The CSR API allows for users with `create` rights to CSRs and `update` rights on `certificatesigningrequests/approval` +where the signer is `kubernetes.io/kube-apiserver-client` to create new client certificates +which allow users to authenticate to the cluster. Those client certificates can have arbitrary +names including duplicates of Kubernetes system components. This will effectively allow for privilege escalation. + +### Token request + +Users with `create` rights on `serviceaccounts/token` can create TokenRequests to issue +tokens for existing service accounts. + +### Control admission webhooks + +Users with control over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations` +can control webhooks that can read any object admitted to the cluster, and in the case of +mutating webhooks, also mutate admitted objects. + + +## Kubernetes RBAC - denial of service risks {#denial-of-service-risks} + +### Object creation denial-of-service {#object-creation-dos} +Users who have rights to create objects in a cluster may be able to create sufficient large +objects to create a denial of service condition either based on the size or number of objects, as discussed in +[etcd used by Kubernetes is vulnerable to OOM attack](https://github.com/kubernetes/kubernetes/issues/107325). This may be +specifically relevant in multi-tenant clusters if semi-trusted or untrusted users +are allowed limited access to a system. + +One option for mitigation of this issue would be to use [resource quotas](/docs/concepts/policy/resource-quotas/#object-count-quota) +to limit the quantity of objects which can be created. \ No newline at end of file