Code change:
Umbrella issue: contains multiple "use cases" for Secrets. However, many of these are mini-tasks. In this issue, I'd like to discuss each of these use cases at a high level to see which we can remove, which we can trim, and which we can move to a new or existing task page. That way, the "Use cases section could even be a bulleted list with links to relevant tasks. Use case: As container environment variables Recommendation: Delete Justification: the goal is achieved in . This also isn't a use case, it's a way to use a secret. Use case: Pod with SSH keys Recommendation: Delete content, keep use case as bullet Justification: the steps add no value beyond the existing task to . Use case: Pods with prod / test credentials Recommendation: Move content to a new or existing task Justification: The content is complex enough that it can be its own task, either as part of or a new task page. Use case: dotfiles in a secret volume Recommendation: Remove steps and keep as bullet point with additional info about why it would be useful. Use case: Secret visible to one container in a Pod Recommendation: Move content to a new or existing task Justification: The content is complex enough that it can be its own task, either as part of or a new task page with actual steps to achieve more than just "secret visible to one container". Perhaps including RBAC steps. If you're interested, review each use case and leave a comment for each agreeing, disagreeing, or providing a different approach to each use case. After we've discussed and settled on an action for these use cases, we can start the actual work! /sig docs /cc
/assign
I think the "Use case: As container environment variables" can be removed as the goal is achieved in too.
Yeah agreed, although I'm separately removing that section and linking it to our existing task page as part of
Let's shift "Use case: Pods with prod/test credentials" and "Use case: secret visible to one container in a Pod" to and attach the link in the use case section as bullet notes.
/triage accepted
Imo the prod/test thing might not even need to move - it can live as an example in the concept but the task steps seem quite basic now that I think about it. Just referencing two Secrets in two different Pods...

Related discussion:
text: ## Uses for Secrets <del> There are three main ways for a Pod to use a Secret: </del> <ins> You can use Secrets for purposes such as the following: </ins> <del> - As [files](#using-secrets-as-files-from-a-pod) in a {{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of its containers. - As [container environment variable](#using-secrets-as-environment-variables). - By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod. </del> <ins> - [Set environment variables for a container](/docs/tasks/inject-data-application/distribute-credentials-secure/#define-container-environment-variables-using-secret-data). - [Provide credentials such as SSH keys or passwords to Pods](/docs/tasks/inject-data-application/distribute-credentials-secure/#provide-prod-test-creds). - [Allow the kubelet to pull container images from private registries](/docs/tasks/configure-pod-container/pull-image-private-registry/). </ins> The Kubernetes control plane also uses Secrets; for example, [bootstrap token Secrets](#bootstrap-token-secrets) are a mechanism to help automate node registration. <ins> ### Use case: dotfiles in a secret volume You can make your data "hidden" by defining a key that begins with a dot. This key represents a dotfile or "hidden" file. For example, when the following secret is mounted into a volume, `secret-volume`, the volume will contain a single file, called `.secret-file`, and the `dotfile-test-container` will have this file present at the path `/etc/secret-volume/.secret-file`. {{< note >}} Files beginning with dot characters are hidden from the output of `ls -l`; you must use `ls -la` to see them when listing directory contents. {{< /note >}} ```yaml apiVersion: v1 kind: Secret metadata: name: dotfile-secret data: .secret-file: dmFsdWUtMg0KDQo= --- apiVersion: v1 kind: Pod metadata: name: secret-dotfiles-pod spec: volumes: - name: secret-volume secret: secretName: dotfile-secret containers: - name: dotfile-test-container image: registry.k8s.io/busybox command: - ls - "-l" - "/etc/secret-volume" volumeMounts: - name: secret-volume readOnly: true mountPath: "/etc/secret-volume" ``` ### Use case: Secret visible to one container in a Pod Consider a program that needs to handle HTTP requests, do some complex business logic, and then sign some messages with an HMAC. Because it has complex application logic, there might be an unnoticed remote file reading exploit in the server, which could expose the private key to an attacker. This could be divided into two processes in two containers: a frontend container which handles user interaction and business logic, but which cannot see the private key; and a signer container that can see the private key, and responds to simple signing requests from the frontend (for example, over localhost networking). With this partitioned approach, an attacker now has to trick the application server into doing something rather arbitrary, which may be harder than getting it to read a file. </ins> ### Alternatives to Secrets Rather than using a Secret to protect confidential data, you can pick from alternatives.