Hide secrets from `docker inspect` command (and commit, debug, etc.)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start by reading the Docker secrets-engine documentation and tracing how se:// values are resolved into container environment variables; the issue does not name implementation files or tests. Investigate how resolved values reach inspectable container configuration and committed images, then define and test behavior that prevents secret values from persisting or being exposed while preserving the intended runtime use.
由索引模型根据 Issue 内容生成。
描述
I understand this is beyond the scope of the secrets engine (which is primarily for guarding secrets access), but wanted to share my first impressions coming into docker pass, and I suspect other users.
My mental model was images get a se:// pointer, so secrets never get pushed to Hub. But the resolved secret value appears to be written back to disk, survive reference deletion and commited into image metadata.
Not sure what set my expectation. Probably secrets usage in cloud Sandboxes so 'credentials never enter the VM', or maybe 'you no longer need plaintext secrets on disk' in the readme, or 'secrets resolve just before the container starts' and 'the same reference can be reused across environments ... resolve against your local OS keychain in dev and against a prod vault in CI' in the docs docs made me think this was ephemeral runtime injection.
docker pass set db-password=supersecret123
cat > compose.yaml <<'EOF'
services:
db:
image: postgres:alpine
environment:
- POSTGRES_PASSWORD=se://db-password
EOF
docker compose up -d
docker inspect $(docker compose ps -q db) --format '{{json .Config.Env}}'
# ["POSTGRES_PASSWORD=supersecret123", ...] <- plaintext secret stored on disk
docker pass rm db-password
docker commit $(docker compose ps -q db) db:snapshot
docker inspect db:snapshot --format '{{json .Config.Env}}'
# ["POSTGRES_PASSWORD=supersecret123", ...] <- baked into any image you commit or push
Mostly concerned about accidental (agentic or otherwise) push/save, and anyone who pull/load the image reads the resolved secret value without access to the original keychain. Keeping the se:// reference in Config.Env would keep the value out of there but I doubt it's that trivial to solve.
- 主要语言
- Go
- 星标
- 95
- 派生
- 18
- 平均合并
- 12 小时 48 分钟
- 30 天内合并 PR
- 38
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
docker/secrets-engine 的其他 Issue
-
Linux keychain: the first D-Bus call per operation (Collections/ReadAlias) has no timeout可能已有人在做 @Benehiko 于 1 天前认领。 未关闭bug
难度 4/5 3-5 天 新手友好度 55/100
docker/secrets-engine#702 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
docker/secrets-engine#682 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
docker/secrets-engine#665 ·
维护者通常 1 天内回复
-
Linux keychain dials a new D-Bus connection per operation, defeating per-entry access confirmation未关闭
难度 5/5 一周以上 新手友好度 42/100
docker/secrets-engine#648 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 65/100
docker/secrets-engine#584 · 1 条评论 · 2 个 reaction ·
维护者通常 1 天内回复
查看 docker/secrets-engine 的全部 Issue
相似的 Issue
-
🕷️ bug
难度 2/5 1-3 小时 新手友好度 70/100
sysadminsmedia/homebox#1805 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
-
难度 2/5 1-3 小时 新手友好度 70/100
router-for-me/CLIProxyAPI#6851 ·
维护者通常 1 天内回复
-
usage: a custom provider's balance meters ("…%" in the balance path) ignore the Left/Used switch未关闭
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
[bug]: docs: Update webhook delete examples to use the correct flag (--webhook-id)可能已有人在做 @MuhammadHassan968 今天认领。 未关闭bug
难度 1/5 1 小时以内 新手友好度 84/100
goharbor/harbor-cli#1127 ·
维护者通常 12 天内回复