Merge pull request #42187 from windsonsea/seracc
Provide a consistent appearance to bullets in service-accounts and rbacpull/42222/head
Kubernetes Prow Robot
GitHub
commit
2a00de295e
|
|
@ -9,10 +9,10 @@ weight: 60
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
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
|
||||
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 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.
|
||||
|
||||
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
|
||||
|
||||
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,
|
||||
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,
|
||||
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 that currently exist in the cluster, but also to all 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 RoleBindings or ClusterRoleBindings. 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)
|
||||
- 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 that currently exist in the cluster, but also to all 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 RoleBindings or ClusterRoleBindings. 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 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:
|
||||
|
||||
- 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.
|
||||
- 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.
|
||||
- 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
|
||||
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
|
||||
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 them where possible, as this gives
|
||||
|
|
@ -76,7 +76,7 @@ to harden cluster rights exist:
|
|||
|
||||
### 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.
|
||||
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
|
||||
|
|
@ -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
|
||||
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.
|
||||
|
||||
### 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
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
### 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) to which they have rights.
|
||||
This access bypasses audit logging and admission control, so care should be taken before
|
||||
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 before
|
||||
granting rights to this resource.
|
||||
|
||||
### 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),
|
||||
users with this right can effectively escalate their privileges.
|
||||
|
||||
### Bind verb
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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.
|
||||
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
|
||||
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
|
||||
|
|
|
|||
|
|
@ -26,18 +26,18 @@ implementing identity-based security policies.
|
|||
Service accounts exist as ServiceAccount objects in the API server. Service
|
||||
accounts have the following properties:
|
||||
|
||||
* **Namespaced:** Each service account is bound to a Kubernetes
|
||||
{{<glossary_tooltip text="namespace" term_id="namespace">}}. Every namespace
|
||||
gets a [`default` ServiceAccount](#default-service-accounts) upon creation.
|
||||
* **Namespaced:** Each service account is bound to a Kubernetes
|
||||
{{<glossary_tooltip text="namespace" term_id="namespace">}}. Every namespace
|
||||
gets a [`default` ServiceAccount](#default-service-accounts) upon creation.
|
||||
|
||||
* **Lightweight:** Service accounts exist in the cluster and are
|
||||
defined in the Kubernetes API. You can quickly create service accounts to
|
||||
enable specific tasks.
|
||||
* **Lightweight:** Service accounts exist in the cluster and are
|
||||
defined in the Kubernetes API. You can quickly create service accounts to
|
||||
enable specific tasks.
|
||||
|
||||
* **Portable:** A configuration bundle for a complex containerized workload
|
||||
might include service account definitions for the system's components. The
|
||||
lightweight nature of service accounts and the namespaced identities make
|
||||
the configurations portable.
|
||||
* **Portable:** A configuration bundle for a complex containerized workload
|
||||
might include service account definitions for the system's components. The
|
||||
lightweight nature of service accounts and the namespaced identities make
|
||||
the configurations portable.
|
||||
|
||||
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
|
||||
|
|
@ -78,10 +78,10 @@ the following scenarios:
|
|||
|
||||
* Your Pods need to communicate with the Kubernetes API server, for example in
|
||||
situations such as the following:
|
||||
* Providing read-only access to sensitive information stored in Secrets.
|
||||
* Granting [cross-namespace access](#cross-namespace), such as allowing a
|
||||
Pod in namespace `example` to read, list, and watch for Lease objects in
|
||||
the `kube-node-lease` namespace.
|
||||
* Providing read-only access to sensitive information stored in Secrets.
|
||||
* Granting [cross-namespace access](#cross-namespace), such as allowing a
|
||||
Pod in namespace `example` to read, list, and watch for Lease objects in
|
||||
the `kube-node-lease` namespace.
|
||||
* Your Pods need to communicate with an external service. For example, a
|
||||
workload Pod requires an identity for a commercially available cloud API,
|
||||
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
|
||||
contexts.
|
||||
|
||||
|
||||
## How to use service accounts {#how-to-use}
|
||||
|
||||
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.
|
||||
1. Grant permissions to the ServiceAccount object using an authorization
|
||||
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.
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
request. The API server checks the validity of that bearer token as follows:
|
||||
|
||||
1. Check the token signature.
|
||||
1. Check whether the token has expired.
|
||||
1. Check whether object references in the token claims are currently valid.
|
||||
1. Check whether the token is currently valid.
|
||||
1. Check the audience claims.
|
||||
1. Checks the token signature.
|
||||
1. Checks whether the token has expired.
|
||||
1. Checks whether object references in the token claims are currently valid.
|
||||
1. Checks whether the token is currently valid.
|
||||
1. Checks the audience claims.
|
||||
|
||||
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
|
||||
|
|
@ -257,15 +256,15 @@ used in your application and nowhere else.
|
|||
[Webhook Token Authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
|
||||
to validate bearer tokens using your own validation service.
|
||||
* 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" %}}
|
||||
* [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:
|
||||
* [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
|
||||
and Access Management (IAM) service, such as from a cloud provider, to
|
||||
authenticate to your cluster.
|
||||
* [Use the CertificateSigningRequest API with client certificates](/docs/tasks/tls/managing-tls-in-a-cluster/).
|
||||
* [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
|
||||
and Access Management (IAM) service, such as from a cloud provider, to
|
||||
authenticate to your 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/).
|
||||
* Use a Device Plugin to access a virtual Trusted Platform Module (TPM), which
|
||||
then allows authentication using a private key.
|
||||
|
|
|
|||
Loading…
Reference in New Issue