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

Move developer content below cluster admins 

Additionally, fixed a couple of markdown links to not line wrap
This commit is contained in:
Shannon Kularathna 2022-08-17 19:23:26 +00:00
parent 502eac3635
commit 8eb3ae60f3
1 changed files with 25 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -18,29 +18,6 @@ your Secrets.
<!-- body -->
### Security recommendations for developers
- Applications still need to protect the value of confidential information after reading it
from an environment variable or volume. For example, your application must avoid logging
the secret data in the clear or transmitting it to an untrusted party.
- If you are defining multiple containers in a Pod, and only one of those
containers needs access to a Secret, define the volume mount or environment
variable configuration so that the other containers do not have access to that
Secret.
- If you configure a Secret through a {{< glossary_tooltip text="manifest" term_id="manifest" >}},
with the secret data encoded as base64, sharing this file or checking it in to a
source repository means the secret is available to everyone who can read the manifest.
Base64 encoding is _not_ an encryption method, it provides no additional confidentiality
over plain text.
- When deploying applications that interact with the Secret API, you should
limit access using
[authorization policies](/docs/reference/access-authn-authz/authorization/) such as
[RBAC](/docs/reference/access-authn-authz/rbac/).
- In the Kubernetes API, `watch` and `list` requests for Secrets within a namespace
are extremely powerful capabilities. Avoid granting this access where feasible, since
listing Secrets allows the clients to inspect the values of every Secret in that
namespace.
## Cluster administrators
### Configure encryption at rest
@ -104,3 +81,28 @@ the data.
For a list of supported providers, refer to
[Providers for the Secret Store CSI Driver](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver).
### Security recommendations for developers
- Applications still need to protect the value of confidential information
after reading it from an environment variable or volume. For example, your
application must avoid logging the secret data in the clear or transmitting
it to an untrusted party.
- If you are defining multiple containers in a Pod, and only one of those
containers needs access to a Secret, define the volume mount or environment
variable configuration so that the other containers do not have access to that
Secret.
- If you configure a Secret through a
{{< glossary_tooltip text="manifest" term_id="manifest" >}}, with the secret
data encoded as base64, sharing this file or checking it in to a source
repository means the secret is available to everyone who can read the
manifest. Base64 encoding is _not_ an encryption method, it provides no
additional confidentiality over plain text.
- When deploying applications that interact with the Secret API, you should
limit access using
[authorization policies](/docs/reference/access-authn-authz/authorization/)
such as [RBAC](/docs/reference/access-authn-authz/rbac/).
- In the Kubernetes API, `watch` and `list` requests for Secrets within a
namespace are extremely powerful capabilities. Avoid granting this access
where feasible, since listing Secrets allows the clients to inspect the
values of every Secret in that namespace.