Introduction

When a Kubernetes Secret is injected into a container as environment variables, those values are read only when the container starts. Updating the Secret object later does not mutate the already running process environment, which is why the pod keeps seeing the old value until it is restarted or replaced.

Why Secret-Based Environment Variables Stay Stale

Environment variables are part of a process startup contract. Kubernetes resolves the Secret reference during pod startup, then passes the resulting values to the container runtime. After that, the process inside the container owns its environment, and Kubernetes does not patch it in place.

A Deployment like this is valid:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: api
5spec:
6  replicas: 1
7  selector:
8    matchLabels:
9      app: api
10  template:
11    metadata:
12      labels:
13        app: api
14    spec:
15      containers:
16        - name: api
17          image: busybox
18          command: ["sh", "-c", "env | grep API_KEY && sleep 3600"]
19          env:
20            - name: API_KEY
21              valueFrom:
22                secretKeyRef:
23                  name: api-secret
24                  key: api-key

If api-secret changes later, the container keeps the old API_KEY value because the shell process is already running.

Mounted Secret Volumes Behave Differently

This is where a lot of confusion comes from. Secret volumes and Secret-backed environment variables are not the same update model.

If you mount a Secret as files:

1volumeMounts:
2  - name: secret-volume
3    mountPath: /etc/secret
4    readOnly: true
5volumes:
6  - name: secret-volume
7    secret:
8      secretName: api-secret

Kubernetes can update the mounted files when the Secret changes. Applications that read the file at runtime can therefore observe updated content without a full pod restart. That behavior does not apply to environment variables.

So the rule is:

• Secret as env var: fixed until container restart
• Secret as mounted file: can update on disk

Whether the application notices the new file content still depends on how the application reads configuration.

Restart the Pods to Pick Up New Env Vars

If the Secret is consumed through env or envFrom, the normal fix is a rollout restart.

kubectl rollout restart deployment/api

That causes new pods to start, and those new pods read the updated Secret value during container startup.

You can also force a new ReplicaSet by changing a pod template annotation:

kubectl patch deployment api \
  -p '{"spec":{"template":{"metadata":{"annotations":{"secret-reload":"2026-03-11T12:00:00Z"}}}}}'

The annotation value itself is not special. It just changes the pod template hash so Kubernetes creates new pods.

Use a Controller If You Want Automatic Restarts

In many teams, Secret rotation should automatically restart workloads that depend on it. Kubernetes does not do that automatically for env vars, so people often use a controller such as a reloader operator.

The workflow becomes:

1. Secret changes.
2. The reloader detects the change.
3. The controller patches the Deployment.
4. Kubernetes rolls the pods.

That gives you predictable behavior without asking every operator to remember a manual restart.

Prefer Mounted Files for Live-Reloadable Applications

If your application can reload config at runtime, a mounted Secret file is often a better fit than env vars. For example, an app can watch a file, reread credentials periodically, or reload TLS material on signal.

That pattern avoids unnecessary pod restarts, but it only works when the application is designed to reread files rather than cache the value once.

Common Pitfalls

The biggest mistake is assuming that because Secret volumes refresh, Secret-backed environment variables must refresh too. Another common issue is updating the Secret successfully but forgetting to restart the workload, which makes it look like Kubernetes ignored the change. Teams also sometimes move sensitive config into env vars when the application would actually be better served by reading mounted files. Finally, an automated reload controller helps only if the workload really references the Secret and the rollout policy is safe for that service.

Summary

• Secret values injected as environment variables are captured only at container startup.
• Updating the Secret does not mutate the environment of already running containers.
• Secret volumes can refresh on disk, which is a different behavior from env vars.
• To pick up new env-var values, restart or roll the pods.
• If you need live reload, prefer mounted Secret files and application logic that rereads them.