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: password: 39528$vdg7Jb ``` <ins> ## Example: Provide prod/test credentials to Pods using Secrets {#provide-prod-test-creds} This example illustrates a Pod which consumes a secret containing production credentials and another Pod which consumes a secret with test environment credentials. 1. Create a secret for prod environment credentials: ```shell kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 ``` The output is similar to: ``` secret "prod-db-secret" created ``` 1. Create a secret for test environment credentials. ```shell kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests ``` The output is similar to: ``` secret "test-db-secret" created ``` {{< note >}} Special characters such as `$`, ``, `*`, `=`, and `!` will be interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping. In most shells, the easiest way to escape the password is to surround it with single quotes (`'`). For example, if your actual password is `S!B*d$zDsb=`, you should execute the command as follows: ```shell kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B*d$zDsb=' ``` You do not need to escape special characters in passwords from files (`--from-file`). {{< /note >}} 1. Create the Pod manifests: ```shell cat <<EOF > pod.yaml apiVersion: v1 kind: List items: - kind: Pod apiVersion: v1 metadata: name: prod-db-client-pod labels: name: prod-db-client spec: volumes: - name: secret-volume secret: secretName: prod-db-secret containers: - name: db-client-container image: myClientImage volumeMounts: - name: secret-volume readOnly: true mountPath: "/etc/secret-volume" - kind: Pod apiVersion: v1 metadata: name: test-db-client-pod labels: name: test-db-client spec: volumes: - name: secret-volume secret: secretName: test-db-secret containers: - name: db-client-container image: myClientImage volumeMounts: - name: secret-volume readOnly: true mountPath: "/etc/secret-volume" EOF ``` Note how the specs for the two Pods differ only in one field; this facilitates creating Pods with different capabilities from a common Pod template. 1. Apply all those objects on the API server by running: ```shell kubectl create -f pod.yaml ``` Both containers will have the following files present on their filesystems with the values for each container's environment: ``` /etc/secret-volume/username /etc/secret-volume/password ``` You could further simplify the base Pod specification by using two service accounts: 1. `prod-user` with the `prod-db-secret` 1. `test-user` with the `test-db-secret` The Pod specification is shortened to: ```yaml apiVersion: v1 kind: Pod metadata: name: prod-db-client-pod labels: name: prod-db-client spec: serviceAccount: prod-db-client containers: - name: db-client-container image: myClientImage ``` </ins> ### References - [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)