Explain namespace subdividing better

pull/36343/head
Tim Allclair 2022-08-29 15:14:28 -07:00
parent 6162bcde28
commit 19894182dc
1 changed files with 8 additions and 5 deletions

View File

@ -102,9 +102,10 @@ includes the contents of all Secrets.
Permission to create workloads (either Pods, or
[workload resources](/docs/concepts/workloads/controllers/) that manage Pods) in a namespace
implicitly grants access to many other resources in that namespace, such as Secrets, ConfigMaps, and
PersistentVolumes, which can be mounted into a Pod. Additionally, since Pods can run as any
[ServiceAccount](/docs/reference/access-authn-authz/service-accounts-admin/), create workload
permissions effectively grants the API access levels of any ServiceAccount in the namespace.
PersistentVolumes that can be mounted in Pods. Additionally, since Pods can run as any
[ServiceAccount](/docs/reference/access-authn-authz/service-accounts-admin/), granting permission
to create workloads also implicitly grants the API access levels of any service account in that
namespace.
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
@ -113,8 +114,10 @@ with the ability to create suitably secure and isolated Pods, you should enforce
You can use [Pod Security admission](/docs/concepts/security/pod-security-admission/)
or other (third party) mechanisms to implement that enforcement.
For these reasons, it is considered best practice to generally grant permissions at the namespace
level, and use caution when subdividing access within a namespace.
For these reasons, namespaces should be used to separate resources requiring different levels of
trust or tenancy. It is still considered best practice to follow [least privilege](#least-privilege)
principles and assign the minimum set of permissions, but boundaries within a namespace should be
considered weak.
### Persistent volume creation