kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #42187 from windsonsea/seracc 

Provide a consistent appearance to bullets in service-accounts and rbac
pull/42222/head
Kubernetes Prow Robot 2023-07-25 13:28:17 -07:00 committed by GitHub
parent cfc7acbbcf ca08498f33
commit 2a00de295e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 78 additions and 79 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

100
content/en/docs/concepts/security/rbac-good-practices.md
View File

@ -9,10 +9,10 @@ weight: 60
<!-- overview --> <!-- overview -->
Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}} is a key security control 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 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 execute their roles. It is important to ensure that, when designing permissions for cluster
users, the cluster administrator understands the areas where privilege escalation could occur, users, the cluster administrator understands the areas where privilege escalation could occur,
to reduce the risk of excessive access leading to security incidents. 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 The good practices laid out here should be read in conjunction with the general
@ -24,46 +24,46 @@ The good practices laid out here should be read in conjunction with the general
### Least privilege ### Least privilege
Ideally, minimal RBAC rights should be assigned to users and service accounts. Only permissions Ideally, minimal RBAC rights should be assigned to users and service accounts. Only permissions
explicitly required for their operation should be used. While each cluster will be different, explicitly required for their operation should be used. While each cluster will be different,
some general rules that can be applied are : some general rules that can be applied are :
- Assign permissions at the namespace level where possible. Use RoleBindings as opposed to - Assign permissions at the namespace level where possible. Use RoleBindings as opposed to
ClusterRoleBindings to give users rights only within a specific namespace. ClusterRoleBindings to give users rights only within a specific namespace.
- Avoid providing wildcard permissions when possible, especially to all resources. - Avoid providing wildcard permissions when possible, especially to all resources.
As Kubernetes is an extensible system, providing wildcard access gives rights As Kubernetes is an extensible system, providing wildcard access gives rights
not just to all object types that currently exist in the cluster, but also to all object types not just to all object types that currently exist in the cluster, but also to all object types
which are created in the future. which are created in the future.
- Administrators should not use `cluster-admin` accounts except where specifically needed. - Administrators should not use `cluster-admin` accounts except where specifically needed.
Providing a low privileged account with Providing a low privileged account with
[impersonation rights](/docs/reference/access-authn-authz/authentication/#user-impersonation) [impersonation rights](/docs/reference/access-authn-authz/authentication/#user-impersonation)
can avoid accidental modification of cluster resources. can avoid accidental modification of cluster resources.
- Avoid adding users to the `system:masters` group. Any user who is a member of this group - 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 bypasses all RBAC rights checks and will always have unrestricted superuser access, which cannot be
revoked by removing RoleBindings or ClusterRoleBindings. As an aside, if a cluster is revoked by removing RoleBindings or ClusterRoleBindings. As an aside, if a cluster is
using an authorization webhook, membership of this group also bypasses that webhook (requests 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) from users who are members of that group are never sent to the webhook)
### Minimize distribution of privileged tokens ### Minimize distribution of privileged tokens
Ideally, pods shouldn't be assigned service accounts that have been granted powerful permissions Ideally, pods shouldn't be assigned service accounts that have been granted powerful permissions
(for example, any of the rights listed under [privilege escalation risks](#privilege-escalation-risks)). (for example, any of the rights listed under [privilege escalation risks](#privilege-escalation-risks)).
In cases where a workload requires powerful permissions, consider the following practices: 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 - 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. 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 - Avoid running powerful pods alongside untrusted or publicly-exposed ones. Consider using
[Taints and Toleration](/docs/concepts/scheduling-eviction/taint-and-toleration/), [Taints and Toleration](/docs/concepts/scheduling-eviction/taint-and-toleration/),
[NodeAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity), or [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) [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 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. situations where less-trustworthy Pods are not meeting the **Restricted** Pod Security Standard.
### Hardening ### Hardening
Kubernetes defaults to providing access which may not be required in every cluster. Reviewing 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. 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 In general, changes should not be made to rights provided to `system:` accounts some options
to harden cluster rights exist: to harden cluster rights exist:
- Review bindings for the `system:unauthenticated` group and remove them where possible, as this gives - Review bindings for the `system:unauthenticated` group and remove them where possible, as this gives
@ -76,7 +76,7 @@ to harden cluster rights exist:
### Periodic review ### Periodic review
It is vital to periodically review the Kubernetes RBAC settings for redundant entries and It is vital to periodically review the Kubernetes RBAC settings for redundant entries and
possible privilege escalations. possible privilege escalations.
If an attacker is able to create a user account with the same name as a deleted user, 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 they can automatically inherit all the rights of the deleted user, especially the
@ -87,7 +87,7 @@ rights assigned to that user.
Within Kubernetes RBAC there are a number of privileges which, if granted, can allow a user or a service account 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. 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 This section is intended to provide visibility of the areas where cluster operators
should take care, to ensure that they do not inadvertently allow for more access to clusters than intended. should take care, to ensure that they do not inadvertently allow for more access to clusters than intended.
### Listing secrets ### Listing secrets
@ -125,7 +125,7 @@ If someone - or some application - is allowed to create arbitrary PersistentVolu
includes the creation of `hostPath` volumes, which then means that a Pod would get access includes the creation of `hostPath` volumes, which then means that a Pod would get access
to the underlying host filesystem(s) on the associated node. Granting that ability is a security risk. to 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, including There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including
reading data from other containers, and abusing the credentials of system services, such as Kubelet. reading data from other containers, and abusing the credentials of system services, such as Kubelet.
You should only allow access to create PersistentVolume objects for: You should only allow access to create PersistentVolume objects for:
@ -135,56 +135,56 @@ You should only allow access to create PersistentVolume objects for:
that are configured for automatic provisioning. that are configured for automatic provisioning.
This is usually setup by the Kubernetes provider or by the operator when installing a CSI driver. 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 create Where access to persistent storage is required trusted administrators should create
PersistentVolumes, and constrained users should use PersistentVolumeClaims to access that storage. PersistentVolumes, and constrained users should use PersistentVolumeClaims to access that storage.
### Access to `proxy` subresource of Nodes ### Access to `proxy` subresource of Nodes
Users with access to the proxy sub-resource of node objects have rights to the Kubelet API, 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. 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 before This access bypasses audit logging and admission control, so care should be taken before
granting rights to this resource. granting rights to this resource.
### Escalate verb ### Escalate verb
Generally, the RBAC system prevents users from creating clusterroles with more rights than the user possesses. Generally, the RBAC system prevents users from creating clusterroles with more rights than the user possesses.
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), 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. users with this right can effectively escalate their privileges.
### Bind verb ### Bind verb
Similar to the `escalate` verb, granting users this right allows for the bypass of Kubernetes Similar to the `escalate` verb, granting users this right allows for the bypass of Kubernetes
in-built protections against privilege escalation, allowing users to create bindings to in-built protections against privilege escalation, allowing users to create bindings to
roles with rights they do not already have. roles with rights they do not already have.
### Impersonate verb ### Impersonate verb
This verb allows users to impersonate and gain the rights of other users in the cluster. 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 Care should be taken when granting it, to ensure that excessive permissions cannot be gained
via one of the impersonated accounts. via one of the impersonated accounts.
### CSRs and certificate issuing ### CSRs and certificate issuing
The CSR API allows for users with `create` rights to CSRs and `update` rights on `certificatesigningrequests/approval` 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 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 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. names including duplicates of Kubernetes system components. This will effectively allow for privilege escalation.
### Token request ### Token request
Users with `create` rights on `serviceaccounts/token` can create TokenRequests to issue Users with `create` rights on `serviceaccounts/token` can create TokenRequests to issue
tokens for existing service accounts. tokens for existing service accounts.
### Control admission webhooks ### Control admission webhooks
Users with control over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations` Users with control over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations`
can control webhooks that can read any object admitted to the cluster, and in the case of can control webhooks that can read any object admitted to the cluster, and in the case of
mutating webhooks, also mutate admitted objects. mutating webhooks, also mutate admitted objects.
## Kubernetes RBAC - denial of service risks {#denial-of-service-risks} ## Kubernetes RBAC - denial of service risks {#denial-of-service-risks}
### Object creation denial-of-service {#object-creation-dos} ### 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 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 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 [etcd used by Kubernetes is vulnerable to OOM attack](https://github.com/kubernetes/kubernetes/issues/107325). This may be

57
content/en/docs/concepts/security/service-accounts.md
View File

@ -26,18 +26,18 @@ implementing identity-based security policies.
Service accounts exist as ServiceAccount objects in the API server. Service Service accounts exist as ServiceAccount objects in the API server. Service
accounts have the following properties: accounts have the following properties:
* **Namespaced:** Each service account is bound to a Kubernetes * **Namespaced:** Each service account is bound to a Kubernetes
{{<glossary_tooltip text="namespace" term_id="namespace">}}. Every namespace {{<glossary_tooltip text="namespace" term_id="namespace">}}. Every namespace
gets a [`default` ServiceAccount](#default-service-accounts) upon creation. gets a [`default` ServiceAccount](#default-service-accounts) upon creation.
* **Lightweight:** Service accounts exist in the cluster and are * **Lightweight:** Service accounts exist in the cluster and are
defined in the Kubernetes API. You can quickly create service accounts to defined in the Kubernetes API. You can quickly create service accounts to
enable specific tasks. enable specific tasks.
* **Portable:** A configuration bundle for a complex containerized workload * **Portable:** A configuration bundle for a complex containerized workload
might include service account definitions for the system's components. The might include service account definitions for the system's components. The
lightweight nature of service accounts and the namespaced identities make lightweight nature of service accounts and the namespaced identities make
the configurations portable. the configurations portable.
Service accounts are different from user accounts, which are authenticated Service accounts are different from user accounts, which are authenticated
human users in the cluster. By default, user accounts don't exist in the Kubernetes human users in the cluster. By default, user accounts don't exist in the Kubernetes
@ -78,10 +78,10 @@ the following scenarios:
* Your Pods need to communicate with the Kubernetes API server, for example in * Your Pods need to communicate with the Kubernetes API server, for example in
situations such as the following: situations such as the following:
* Providing read-only access to sensitive information stored in Secrets. * Providing read-only access to sensitive information stored in Secrets.
* Granting [cross-namespace access](#cross-namespace), such as allowing a * Granting [cross-namespace access](#cross-namespace), such as allowing a
Pod in namespace `example` to read, list, and watch for Lease objects in Pod in namespace `example` to read, list, and watch for Lease objects in
the `kube-node-lease` namespace. the `kube-node-lease` namespace.
* Your Pods need to communicate with an external service. For example, a * Your Pods need to communicate with an external service. For example, a
workload Pod requires an identity for a commercially available cloud API, workload Pod requires an identity for a commercially available cloud API,
and the commercial provider allows configuring a suitable trust relationship. and the commercial provider allows configuring a suitable trust relationship.
@ -92,7 +92,6 @@ the following scenarios:
ServiceAccount identity of different Pods to group those Pods into different ServiceAccount identity of different Pods to group those Pods into different
contexts. contexts.
## How to use service accounts {#how-to-use} ## How to use service accounts {#how-to-use}
To use a Kubernetes service account, you do the following: To use a Kubernetes service account, you do the following:
@ -101,7 +100,7 @@ To use a Kubernetes service account, you do the following:
client like `kubectl` or a manifest that defines the object. client like `kubectl` or a manifest that defines the object.
1. Grant permissions to the ServiceAccount object using an authorization 1. Grant permissions to the ServiceAccount object using an authorization
mechanism such as mechanism such as
[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/). [RBAC](/docs/reference/access-authn-authz/rbac/).
1. Assign the ServiceAccount object to Pods during Pod creation. 1. Assign the ServiceAccount object to Pods during Pod creation.
If you're using the identity from an external service, If you're using the identity from an external service,
@ -147,7 +146,7 @@ API and mounts the token as a
By default, Kubernetes provides the Pod By default, Kubernetes provides the Pod
with the credentials for an assigned ServiceAccount, whether that is the with the credentials for an assigned ServiceAccount, whether that is the
`default` ServiceAccount or a custom ServiceAccount that you specify. `default` ServiceAccount or a custom ServiceAccount that you specify.
To prevent Kubernetes from automatically injecting To prevent Kubernetes from automatically injecting
credentials for a specified ServiceAccount or the `default` ServiceAccount, set the credentials for a specified ServiceAccount or the `default` ServiceAccount, set the
@ -210,11 +209,11 @@ acting as a ServiceAccount tries to communicate with the Kubernetes API server,
the client includes an `Authorization: Bearer <token>` header with the HTTP the client includes an `Authorization: Bearer <token>` header with the HTTP
request. The API server checks the validity of that bearer token as follows: request. The API server checks the validity of that bearer token as follows:
1. Check the token signature. 1. Checks the token signature.
1. Check whether the token has expired. 1. Checks whether the token has expired.
1. Check whether object references in the token claims are currently valid. 1. Checks whether object references in the token claims are currently valid.
1. Check whether the token is currently valid. 1. Checks whether the token is currently valid.
1. Check the audience claims. 1. Checks the audience claims.
The TokenRequest API produces _bound tokens_ for a ServiceAccount. This The TokenRequest API produces _bound tokens_ for a ServiceAccount. This
binding is linked to the lifetime of the client, such as a Pod, that is acting binding is linked to the lifetime of the client, such as a Pod, that is acting
@ -257,15 +256,15 @@ used in your application and nowhere else.
[Webhook Token Authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) [Webhook Token Authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
to validate bearer tokens using your own validation service. to validate bearer tokens using your own validation service.
* Provide your own identities to Pods. * Provide your own identities to Pods.
* [Use the SPIFFE CSI driver plugin to provide SPIFFE SVIDs as X.509 certificate pairs to Pods](https://cert-manager.io/docs/projects/csi-driver-spiffe/). * [Use the SPIFFE CSI driver plugin to provide SPIFFE SVIDs as X.509 certificate pairs to Pods](https://cert-manager.io/docs/projects/csi-driver-spiffe/).
{{% thirdparty-content single="true" %}} {{% thirdparty-content single="true" %}}
* [Use a service mesh such as Istio to provide certificates to Pods](https://istio.io/latest/docs/tasks/security/cert-management/plugin-ca-cert/). * [Use a service mesh such as Istio to provide certificates to Pods](https://istio.io/latest/docs/tasks/security/cert-management/plugin-ca-cert/).
* Authenticate from outside the cluster to the API server without using service account tokens: * Authenticate from outside the cluster to the API server without using service account tokens:
* [Configure the API server to accept OpenID Connect (OIDC) tokens from your identity provider](/docs/reference/access-authn-authz/authentication/#openid-connect-tokens). * [Configure the API server to accept OpenID Connect (OIDC) tokens from your identity provider](/docs/reference/access-authn-authz/authentication/#openid-connect-tokens).
* Use service accounts or user accounts created using an external Identity * Use service accounts or user accounts created using an external Identity
and Access Management (IAM) service, such as from a cloud provider, to and Access Management (IAM) service, such as from a cloud provider, to
authenticate to your cluster. authenticate to your cluster.
* [Use the CertificateSigningRequest API with client certificates](/docs/tasks/tls/managing-tls-in-a-cluster/). * [Use the CertificateSigningRequest API with client certificates](/docs/tasks/tls/managing-tls-in-a-cluster/).
* [Configure the kubelet to retrieve credentials from an image registry](/docs/tasks/administer-cluster/kubelet-credential-provider/). * [Configure the kubelet to retrieve credentials from an image registry](/docs/tasks/administer-cluster/kubelet-credential-provider/).
* Use a Device Plugin to access a virtual Trusted Platform Module (TPM), which * Use a Device Plugin to access a virtual Trusted Platform Module (TPM), which
then allows authentication using a private key. then allows authentication using a private key.