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

Improve the RBAC policies section 

- Change the heading to be more goal-oriented and add an anchor
- Separate list items into 'component' and 'human' users
- Add info about get access and third-party authorization mechanisms for finer control
- Add caution for granting list access
This commit is contained in:
Shannon Kularathna 2022-09-21 16:14:45 +00:00
parent 6ca919d4bd
commit d8132bcd35
1 changed files with 15 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
content/en/docs/concepts/security/secrets-good-practices.md
View File

@ -27,25 +27,24 @@ improve the security of confidential information in the cluster.
By default, Secret objects are stored unencrypted in {{<glossary_tooltip
term_id="etcd" text="etcd">}}. You should configure encryption of your Secret
data in `etcd`. For instructions, refer to [Encrypt Secret data at
rest](/docs/tasks/administer-cluster/encrypt-data/).
data in `etcd`. For instructions, refer to
[Encrypt Secret Data at Rest](/docs/tasks/administer-cluster/encrypt-data/).
### Configure RBAC policies for Secrets
### Configure least-privilege access to Secrets {#least-privilege-secrets}
When planning your {{<glossary_tooltip term_id="rbac" text="Role-based Access Control">}} [(RBAC)](/docs/reference/access-authn-authz/rbac/) policies,
consider the following guidelines for `Secret` objects. You should also follow the other guidelines in [RBAC good practices](/docs/concepts/security/rbac-good-practices).
When planning your access control mechanism, such as Kubernetes
{{<glossary_tooltip term_id="rbac" text="Role-based Access Control">}} [(RBAC)](/docs/reference/access-authn-authz/rbac/),
consider the following guidelines for access to `Secret` objects. You should
also follow the other guidelines in
[RBAC good practices](/docs/concepts/security/rbac-good-practices).
{{< caution >}}
A user who can create a Pod that uses a Secret can also see the value of that Secret. Even
if cluster policies do not allow a user to read the Secret directly, the same user could
have access to run a Pod that then exposes the Secret.
{{< /caution >}}
- Restrict `watch` or `list` access to only the most privileged, system-level
components.
- In the API server, objects (including Secrets) are persisted into
{{< glossary_tooltip term_id="etcd" >}}; therefore:
- Only allow cluster admistrators to access `etcd`. This includes read-only access.
- **Components**: Restrict `watch` or `list` access to only the most
privileged, system-level components. Only grant `get` access for Secrets if
the component's normal behavior requires it.
- **Humans**: Restrict `get`, `watch`, or `list` access to Secrets. Only allow
cluster admistrators to access `etcd`. This includes read-only access. For
more complex access control, such as restricting access to Secrets with
specific annotations, consider using third-party authorization mechanisms.
{{< caution >}}
Granting `list` access to Secrets implicitly lets the subject fetch the