Support for docker secrets exported as environment variables
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by tracing how the Docker CLI parses and forwards secret definitions, then determine whether environment-variable export belongs in this repository or in Docker's engine or Swarm implementation. Done requires an agreed configuration syntax, clarified behavior alongside the existing file mount, and tests covering the proposed option.
Written by the indexing model from the issue text.
Description
Docker secrets are intentionally mounted into containers as files under /run/secrets/, which is a secure default. However, many applications and frameworks expect configuration via environment variables rather than files. As a result, users frequently resort to workarounds like:
entrypoint: >
sh -c "export API_KEY=$(cat /run/secrets/api_key) && exec myapp"
This pattern is widely used and effectively gives the container an environment variable anyway — just with more boilerplate and no additional security compared to a built-in feature.
Providing an optional way to export a secret as an environment variable would significantly improve ergonomics in cases where this pattern is required.
Kubernetes, for example, supports this functionality:
https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/#define-a-container-environment-variable-with-data-from-a-single-secret
Docker could offer an equivalent mechanism with a syntax like:
secrets:
- secret: api_key
as_env: APP_API_KEY
This would avoid shell-based workarounds while keeping the current file-mount behavior as the default.
For example, in co-op cloud, which packages open source applications using docker swarm, there are many applications which require secrets as environment variables and this would be a great improvement on app packaging.
- Dominant language
- Go
- Stars
- 6.1k
- Forks
- 2.2k
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 43
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from docker/cli
-
kind/bug status/0-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
kind/feature status/0-triage
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
kind/bug status/0-triage
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
kind/bug status/0-triage
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
Similar issues
-
textual definition
Difficulty 1/5 Under an hour Newbie friendliness 90/100
geneontology/go-ontology#32653 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
-
needs design
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Priority/High ready-for-agent Severity/Major Type/Bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100