Introduction

If you are working with a Kubernetes Deployment, the secure pattern is not to hard-code secrets directly into the deployment manifest. The normal approach is to create a Kubernetes Secret object and reference it from the Deployment so the container receives the values as environment variables at runtime.

Do not put plaintext secrets directly in the Deployment

This is the insecure pattern:

env:
  - name: DB_PASSWORD
    value: super-secret-password

It works technically, but it exposes the secret in the Deployment manifest, version control, review tools, and shell history. That defeats most of the point of separating configuration from code.

Create a Secret and reference it from the pod spec

A better approach is to define a Secret separately and then use valueFrom.secretKeyRef inside the Deployment.

1apiVersion: v1
2kind: Secret
3metadata:
4  name: app-secrets
5type: Opaque
6stringData:
7  DB_PASSWORD: super-secret-password
8  API_KEY: abc123

Then reference individual keys from the Deployment.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: my-app
5spec:
6  replicas: 1
7  selector:
8    matchLabels:
9      app: my-app
10  template:
11    metadata:
12      labels:
13        app: my-app
14    spec:
15      containers:
16        - name: my-app
17          image: my-app:latest
18          env:
19            - name: DB_PASSWORD
20              valueFrom:
21                secretKeyRef:
22                  name: app-secrets
23                  key: DB_PASSWORD
24            - name: API_KEY
25              valueFrom:
26                secretKeyRef:
27                  name: app-secrets
28                  key: API_KEY

This keeps the deployment manifest free of literal secret values.

Use envFrom when you want all keys imported

If the secret contains several environment variables and you want to expose all of them, envFrom can reduce boilerplate.

envFrom:
  - secretRef:
      name: app-secrets

This is convenient, but it is less explicit. Use it when the whole secret belongs to the container. If you want tighter control, use individual env entries.

Understand what environment variables do and do not protect

Referencing a Kubernetes Secret is better than writing plaintext in the Deployment, but environment variables are not magic. Once injected into a running process, the values may still be visible to application code, logs, crash dumps, or debugging tools if handled carelessly.

So the security improvement is real, but it is not complete by itself. Good secret hygiene still includes:

• avoiding accidental logging
• limiting RBAC access to the Secret object
• rotating secrets regularly
• encrypting secrets at rest where appropriate

Prefer external secret managers when the environment requires them

For many teams, native Kubernetes Secrets are sufficient. For stricter environments, secrets may come from Vault, AWS Secrets Manager, GCP Secret Manager, or a controller such as External Secrets Operator.

The Deployment pattern is still similar: the pod receives environment variables or mounted files, but the source of truth is an external system instead of a manually created Kubernetes Secret.

Environment variable versus volume mount

Environment variables are convenient for libraries that already read settings like DB_PASSWORD or API_KEY. Volume mounts are often better for certificates, private keys, or larger structured configuration.

Choose the format that matches how the application consumes the secret. Do not force every secret into an environment variable just because it is easy.

Common Pitfalls

• Hard-coding secret values directly in the Deployment YAML.
• Storing base64-encoded secret manifests in source control and treating that as real encryption.
• Importing every key with envFrom when only one or two variables are actually needed.
• Logging environment variables during startup or debugging.
• Forgetting that secret injection solves distribution, not all aspects of runtime secrecy.

Summary

• In a Kubernetes Deployment, set secrets through Secret references rather than literal value fields.
• Use valueFrom.secretKeyRef for explicit mapping or envFrom for bulk import.
• Keep secret values out of Deployment source files whenever possible.
• Environment variables are useful, but they still require careful runtime handling.
• For stricter environments, consider external secret-management systems feeding Kubernetes.