From 8eb3ae60f3f0917d55a16903d86adf6d97a3afbf Mon Sep 17 00:00:00 2001 From: Shannon Kularathna Date: Wed, 17 Aug 2022 19:23:26 +0000 Subject: [PATCH] Move developer content below cluster admins Additionally, fixed a couple of markdown links to not line wrap --- .../security/secrets-good-practices.md | 48 ++++++++++--------- 1 file changed, 25 insertions(+), 23 deletions(-) diff --git a/content/en/docs/concepts/security/secrets-good-practices.md b/content/en/docs/concepts/security/secrets-good-practices.md index 32526be656..18a6047157 100644 --- a/content/en/docs/concepts/security/secrets-good-practices.md +++ b/content/en/docs/concepts/security/secrets-good-practices.md @@ -18,29 +18,6 @@ your Secrets. -### 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.