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

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

@ -28,21 +28,21 @@ Ideally, minimal RBAC rights should be assigned to users and service accounts. O
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
@ -50,14 +50,14 @@ Ideally, pods shouldn't be assigned service accounts that have been granted powe
(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
@ -181,10 +181,10 @@ Users with control over `validatingwebhookconfigurations` or `mutatingwebhookcon
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

55
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,
@ -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.