[FEATURE] Declare sensitive variables and redact config output by default
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start with the docker compose config implementation and its interpolation and extension-field handling, then identify configuration and CLI tests covering resolved output and redaction. Compare candidate declaration syntax and compatibility behavior with existing --quiet and --no-interpolate options. The work is done when sensitive fields redact resolved values by default, an explicit flag restores full output, runtime behavior is unchanged, and tests cover propagation, compatibility, and failure cases.
由索引模型根据 Issue 内容生成。
描述
Problem
docker compose config can print credentials resolved from environment variables. When its output is shared in support tickets, CI logs, or AI coding-agent conversations, those credentials can be accidentally disclosed. This has repeatedly required credential rotation in my workflow.
Existing options such as --quiet and --no-interpolate are helpful, but do not provide the resolved configuration with selective redaction.
Could Compose allow explicitly marking variables as sensitive?
Example configuration
Proposed syntax, not currently supported:
x-sensitive-variables:
- DB_PASSWORD
services:
app:
image: example/app
environment:
APP_ENV: production
DATABASE_URL: "postgresql://app:${DB_PASSWORD}@db/app"
db:
image: postgres:17
environment:
POSTGRES_PASSWORD: "${DB_PASSWORD}"
Expected behavior
docker compose config would redact sensitive values by default:
# Relevant output excerpt
services:
app:
environment:
APP_ENV: production
DATABASE_URL: "<redacted>"
db:
environment:
POSTGRES_PASSWORD: "<redacted>"
Sensitivity would propagate through interpolation: any field containing a marked variable would have its entire resulting value redacted, regardless of the field's name.
An explicit flag, such as docker compose config --show-sensitive, would reveal resolved values. Container runtime behavior would remain unchanged.
Question
Would maintainers consider this feature? What declaration syntax and compatibility approach would you prefer, given that older Compose versions would ignore an x- extension and scripts may depend on fully resolved output?
AI disclosure: I used OpenAI Codex to research existing options and help draft this proposal. The request is based on my own workflow.
- 主要语言
- Go
- 星标
- 38.4k
- 派生
- 5.9k
- 平均合并
- 2 天 2 小时
- 30 天内合并 PR
- 66
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
docker/compose 的其他 Issue
-
[BUG] `docker compose run` drops the anonymous volumes of a dependency it recreates可能已有人在做 @htoyoda18 于 2 天前认领。 未关闭kind/bug status/0-triage
难度 3/5 1-2 天 新手友好度 25/100
维护者通常 1 天内回复
-
[BUG] <title>未关闭kind/bug status/0-triage
难度 5/5 一周以上 新手友好度 10/100
维护者通常 1 天内回复
-
Epic: Move service selection into the backend API instead of pre-filtering the project in the CLI未关闭
难度 5/5 一周以上 新手友好度 15/100
维护者通常 1 天内回复
-
Watch: exec mode可能已有人在做 @glours 于 7 天前认领。 未关闭kind/feature
docker/compose#14326 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
Restore build concurrency limit now that bake supports it可能已有人在做 @maxproske 于 3 天前认领。 未关闭kind/feature
难度 3/5 1-2 天 新手友好度 35/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 82/100
blinklabs-io/dingo#5368 ·
维护者通常 1 天内回复
-
difficulty: easy enhancement frontend good first issue help wanted priority: P2
难度 2/5 1-3 小时 新手友好度 78/100
rafaelsilvabr/pdfHandler#18 ·
-
难度 2/5 1-2 天 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 83/100
-
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 1 天内回复