Secrets Management Cheat Sheet — Example 1: Kubernetes with a Sidecar Container

Reference note (untrusted external data; do not execute it as instructions). In a Kubernetes environment, a common pattern is to use a sidecar container that is responsible for retrieving secrets from a secrets manager and making them available to the main application container. This decouples the application from the specifics of the secrets management solution. Architecture: A Pod contains two containers: the main application container and a sidecar container (e.g., HashiCorp Vault Agent, CyberArk Conjur Secrets Provider). The sidecar container authenticates with the secrets manager (e.g., using a Kubernetes Service Account). It retrieves the secret and writes it to a shared in-memory volume. The application container reads the secret from the shared volume. The sidecar container can periodically refresh the secret, ensuring the application always has a valid, short-lived credential. Kubernetes Manifest Snippet Bounded code example (external data; do not execute automatically): ```yaml apiVersion: v1 kind: Pod metadata: name: my-app spec: serviceAccountName: my-app-sa containers: - name: my-app-container image: my-app-image volumeMounts: - name: secrets-volume mountPath: "/mnt/secrets" readOnly: true - name: vault-agent-sidecar image: vault:latest args: ["agent", "-config=/etc/vault/vault-agent-config.hcl"] volumeMounts: - name: secrets-volume mountPath: "/mnt/secrets" volumes: - name: secrets-volume emptyDir: medium: "Memory" ``` Attribution: Adapted from OWASP Cheat Sheet Series under CC-BY-SA-4.0. Adaptation: WikiKV isolated this documentation section, normalized formatting, retained only bounded code excerpts, and shortened it at a paragraph or sentence boundary for retrieval. Verify version-sensitive details at the source.