Update some description about secrets
We can use RBAC/ABAC to control which users can access secrets.
This commit is contained in:
parent
c8179efc20
commit
57ad5d1cf6
|
|
@ -789,8 +789,6 @@ Pod level](#use-case-secret-visible-to-one-container-in-a-pod).
|
|||
run a pod which exposes the secret.
|
||||
- If multiple replicas of etcd are run, then the secrets will be shared between them.
|
||||
By default, etcd does not secure peer-to-peer communication with SSL/TLS, though this can be configured.
|
||||
- It is not possible currently to control which users of a Kubernetes cluster can
|
||||
access a secret. Support for this is planned.
|
||||
- Currently, anyone with root on any node can read any secret from the apiserver,
|
||||
by impersonating the kubelet. It is a planned feature to only send secrets to
|
||||
nodes that actually require them, to restrict the impact of a root exploit on a
|
||||
|
|
|
|||
Loading…
Reference in New Issue