whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update some description about secrets

Browse Source 
We can use RBAC/ABAC to control which users can access secrets.
This commit is contained in:
Cao Shufeng
2017-03-14 03:45:46 -04:00
committed by Andrew Chen
parent c8179efc20
commit 57ad5d1cf6
1 changed files with 0 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/user-guide/secrets/index.md
-2
View File
@@ -789,8 +789,6 @@ Pod level](#use-case-secret-visible-to-one-container-in-a-pod).
run a pod which exposes the secret. run a pod which exposes the secret.
- If multiple replicas of etcd are run, then the secrets will be shared between them. - 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. 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, - 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 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 nodes that actually require them, to restrict the impact of a root exploit on a