Introduction

Yes, a .env file can be the source for a Kubernetes Secret, but you usually do not want to source it first. kubectl can already read env-style key-value pairs directly, which avoids unnecessary shell expansion and keeps the workflow simpler.

That distinction matters because source .env changes your current shell state. In automation and CI pipelines, that can leak variables into later steps in ways that are easy to miss.

Use --from-env-file First

The most direct solution is kubectl create secret generic with --from-env-file.

kubectl create secret generic app-config \
  --from-env-file=.env

If .env contains content such as this:

1DB_HOST=db.internal
2DB_USER=app_user
3DB_PASSWORD=s3cr3t
4API_KEY=abc123

then Kubernetes creates a secret with one entry per line. This is usually the best answer to the question because it skips shell quoting issues and avoids leaking values into your interactive environment.

Generate YAML Instead of Creating Immediately

Many teams prefer declarative manifests instead of one-off imperative commands. You can still use the env file as the source and ask kubectl to emit YAML.

kubectl create secret generic app-config \
  --from-env-file=.env \
  --dry-run=client -o yaml

That command prints a Secret manifest to standard output. If you want to apply it directly, pipe it into kubectl apply.

kubectl create secret generic app-config \
  --from-env-file=.env \
  --dry-run=client -o yaml | kubectl apply -f -

This keeps the source of truth in the .env file while still fitting into a manifest-driven workflow.

When source Makes Sense

You can source the file first, but it is usually a fallback rather than the best default. One case is when you need to transform or combine values before creating the secret.

1set -a
2source .env
3set +a
4
5kubectl create secret generic app-config \
6  --from-literal=DB_HOST="$DB_HOST" \
7  --from-literal=DB_USER="$DB_USER" \
8  --from-literal=DB_PASSWORD="$DB_PASSWORD"

This works, but it has drawbacks. The variables now exist in your shell environment, shell syntax inside the file matters, and accidental expansion can create hard-to-debug mistakes. For a plain key-value file, --from-env-file is cleaner.

Remember What a Kubernetes Secret Is

Kubernetes stores secret values as base64-encoded data, not as magically encrypted content. Whether that is sufficient depends on your cluster configuration, access controls, and whether you have encryption at rest enabled.

Using a .env file is therefore only one part of the story. You still need to treat the original file, the generated manifest, and any logs that mention these values as sensitive material.

Keep the Env File Format Simple

--from-env-file works best with plain KEY=value lines. Comments and blank lines are generally fine, but shell-heavy constructs, command substitution, and complex quoting rules are better avoided. If the file behaves like a shell script, use a real template step instead of assuming kubectl will interpret it the same way.

Reference the Secret in a Pod

After creating the secret, mount it into a workload or expose selected keys as environment variables.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: app-demo
5spec:
6  containers:
7    - name: app
8      image: nginx
9      env:
10        - name: DB_HOST
11          valueFrom:
12            secretKeyRef:
13              name: app-config
14              key: DB_HOST
15        - name: DB_PASSWORD
16          valueFrom:
17            secretKeyRef:
18              name: app-config
19              key: DB_PASSWORD

This is the point of the conversion: keep sensitive configuration in Kubernetes and let workloads consume it through normal cluster primitives.

Common Pitfalls

• Assuming a .env file is encrypted. It is not; it is only a text format.
• Committing .env files or generated secret YAML into version control.
• Expecting every shell-oriented .env feature to work with --from-env-file. Keep the file in simple KEY=value form.
• Forgetting that changing the .env file does nothing until you recreate or reapply the Kubernetes secret.

Summary

• Yes, you can use a .env file to create a Kubernetes secret.
• In most cases, prefer kubectl create secret generic --from-env-file=.env over source .env.
• Use --dry-run=client -o yaml when you want a manifest-based workflow.
• Only source the file when you truly need shell-side transformation or composition.
• Treat both the .env file and the generated secret data as sensitive material.