Docker Secrets完整指南:安全管理容器密码和API密钥的最佳实践

凌晨3点半,我的手机疯狂震动。

睁眼一看——24条短信,全是数据库异常告警。心脏猛地一沉:赶紧打开笔记本,SSH连上服务器。数据库连接数爆满,有人在暴力扫描。

冷汗瞬间就下来了。

查日志,发现攻击者直接用了正确的密码——那个我三个月前写在docker-compose.yml里,觉得”反正是私有仓库不会有事”的MySQL密码。后来才想起来,上个月有个实习生fork了项目到自己的公开仓库练手…

说实话,那晚真的被吓到了。更可怕的是,后来我发现周围很多人都在这样做:把密码直接写配置文件,用环境变量就觉得安全了。甚至有朋友跟我说”我的仓库是私有的,没关系”。

但你知道吗?就算不考虑代码泄露,只要有人能执行docker inspect命令,所有环境变量都能看到——明文。

这篇文章我想聊聊容器密码管理这件事。不是因为我很懂,恰恰相反,是因为我踩过坑,交了学费,才慢慢搞明白哪些做法真的危险,哪些工具真的有用。

如果你的项目还在用环境变量管理数据库密码、API密钥这些敏感信息,真的建议往下看看。不需要多高深的技术,只是换个思路,就能避开很多风险。

为什么环境变量不安全?

三种常见的不安全做法

我先说说自己犯过的错,看你有没有也这样做过。

第一种:直接写在Dockerfile里

FROM node:18
ENV DATABASE_PASSWORD=MyS3cr3tP@ssw0rd
ENV API_KEY=sk-1234567890abcdef

这个是最糟糕的。因为Dockerfile的每一条指令都会创建一层镜像层,就算你后面用ENV DATABASE_PASSWORD=""去覆盖,密码依然藏在历史层里。任何拿到你镜像的人,用docker history <镜像名>就能翻出来。

不相信?我当时也不信,直到有个同事给我演示了一遍。他随手拉了个我们公司的内部镜像,几条命令就把AWS的Access Key给扒出来了。那个Key是三年前某个离职同事留下的,一直忘了删。

第二种:写在docker-compose.yml里

version: '3.8'
services:
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: SuperSecretPassword123
      MYSQL_DATABASE: myapp

这个我用了很久。理由很简单:方便。一个docker-compose up -d就起来了,开发调试效率高。

问题在哪?这文件得提交到Git啊。就算仓库是私有的,但凡有一个人权限管理没做好,或者像我遇到的那样,有人fork到公开仓库,密码就全泄露了。

第三种:用.env文件但纳入版本控制

# .env文件
DB_PASSWORD=password123
API_SECRET=abcdef123456

这个看起来聪明点,把敏感信息抽到单独的.env文件,然后docker-compose里用${DB_PASSWORD}引用。

但很多人(包括曾经的我)会把.env也提交到Git,觉得”团队其他人也得能跑起来啊”。结果嘛——跟直接写在docker-compose里没区别。

正确做法是把.env加到.gitignore,然后给一个.env.example模板。但老实说,一开始谁会想这么多?

环境变量的三大安全隐患

就算你把.env加到了.gitignore,就算代码没泄露,环境变量依然不安全。为啥?

隐患1:docker inspect能看到一切

试试这个命令:

docker inspect <容器ID> | grep -A 20 "Env"

所有环境变量,包括密码,全部明文显示。

这意味着什么?任何能访问Docker守护进程的人——运维、DevOps、有服务器权限的开发者——都能看到你的密码。不需要破解,不需要什么高级技术,就是一条命令的事。

我之前在一个创业公司待过,大家都有生产服务器的SSH权限,图个方便。结果有一天新来的前端同学好奇”容器里装了啥”,随手一条docker inspect,数据库密码就这么摆在屏幕上了。还好是自己人,要是有心人呢?

隐患2:容器内的进程可以读取

环境变量不仅Docker能看到,容器内的所有进程也能看到。在Linux里,进程的环境变量保存在/proc/<PID>/environ文件里。

这意味着,如果你的应用有任何一个依赖库存在漏洞,被人注入了代码,那攻击者可以直接读取环境变量拿到密码。

去年有个Node.js的库被爆出后门,就是偷偷读取环境变量里的AWS凭证然后发到外网。受影响的项目超过几万个。

隐患3:日志里可能会泄露

这个更隐蔽。

很多时候应用启动会打印配置信息,或者出错时会把环境变量dump出来记到日志。日志文件通常权限管理比较松,甚至会被传到集中的日志系统(比如ELK)。

我见过有团队把所有容器日志汇总到一个Elasticsearch集群,结果安全审计时发现,日志里躺着几百条数据库密码…开发人员在调试时习惯console.log(process.env),然后就忘了删。

更麻烦的是,一旦密码进了日志,很难彻底清除——备份、归档、各种地方都有副本。

真实案例分享

网上这类事故其实不少,只是很多公司不会公开。我说几个我知道的:

案例1:GitHub公开仓库泄露

2023年有个数据分析显示,GitHub上有超过100万个公开仓库包含API密钥、数据库密码等敏感信息。不是说这些项目的开发者傻,而是很多时候就是一时疏忽——测试时用的配置忘了删,或者不小心把.env提交了。

有个做机器学习的朋友,他们团队把训练代码开源到GitHub,顺手把AWS凭证也推上去了。24小时内,就有人用他们的凭证开了十几台GPU实例挖矿。账单直接飙到两万多美元。

案例2:CI/CD pipeline历史泄露

CI/CD工具(Jenkins、GitLab CI等)的构建历史通常会保留环境变量日志。如果没做好脱敏处理,这些日志就是密码库。

我遇到过一个项目,用GitLab CI自动部署。有个同事离职前把仓库权限开给了一个外包团队,结果外包那边有人进去翻历史构建日志,拿到了生产数据库的连接信息。幸好他们是想帮忙优化,主动告诉我们的,要是居心不良呢?

案例3:Docker Hub镜像扫描

阿里云有个安全报告显示,他们扫描了公开的Docker镜像,发现76%存在安全漏洞,其中不少包含硬编码的凭证。

有些企业图省事,把内部应用镜像推到公开的Docker Hub,以为”没人会专门来扒我们小公司的镜像”。但现在有很多自动化的爬虫和安全扫描工具,专门干这事。你的镜像一推上去,可能几分钟内就被扫了一遍。

说这些不是为了吓人,是想说——这些问题真的在发生,而且比你想象的更普遍。关键是,其实是有办法避免的。

Docker Secrets是什么?如何使用?

Docker Secrets工作原理

好,现在来说解决方案。

Docker Secrets是Docker官方提供的密钥管理机制。简单说,它的核心思路是:密钥不再是明文字符串,而是加密的文件。

工作流程是这样的:

1. 你创建一个secret,Docker会把它加密存储在集群的Raft日志里
2. 当容器需要这个secret时,Docker通过加密的TLS连接把它传输过去
3. Secret以文件的形式挂载到容器内的/run/secrets/目录
4. 这个目录是tmpfs——纯内存文件系统,不会写入磁盘
5. 容器停止后,secret自动从内存清除

关键点来了:secret不会出现在环境变量里,不会出现在docker inspect输出里,不会被docker commit打包进镜像。

听起来有点抽象?没事,我第一次看Docker文档也是云里雾里的。直接上手试试就明白了。

先说一下限制:Docker Secrets原生只能在Swarm模式下用。这点刚开始挺让我困扰的——我就是本地开发,单机跑,为啥不能用?

后来发现docker-compose也支持file secrets(功能弱点,但至少能用)。如果是生产环境的集群,那直接用Swarm mode或者Kubernetes都行。

手把手实战:MySQL + WordPress案例

来个完整的例子。假设我们要部署一个WordPress博客,需要保护MySQL的root密码和用户密码。

第一步:创建secret文件

先把密码写到本地文件(注意:这些文件不要提交到Git):

echo "MyRootPassword123" > db_root_password.txt
echo "MyUserPassword456" > db_password.txt

第二步:初始化Swarm(如果还没初始化)

docker swarm init

是的,就这一条命令。如果你的机器还没开启Swarm模式,运行这个就行。单机也可以用Swarm,不一定要多台机器组集群。

第三步:创建Docker secrets

docker secret create mysql_root_password db_root_password.txt
docker secret create mysql_password db_password.txt

创建完后,立即删除本地的密码文件:

rm db_root_password.txt db_password.txt

这一步很重要。文件一旦被Docker读取并加密存储,本地明文就该销毁了。

验证一下secrets是否创建成功:

docker secret ls

你会看到类似这样的输出:

ID                          NAME                  CREATED         UPDATED
abc123...                   mysql_root_password   5 seconds ago   5 seconds ago
def456...                   mysql_password        3 seconds ago   3 seconds ago

注意:你看不到secret的内容,只能看到名字和元数据。这就是重点——一旦创建,即使是管理员也拿不到明文。

第四步:创建docker-compose.yml

version: '3.8'

secrets:
  mysql_root_password:
    external: true
  mysql_password:
    external: true

services:
  db:
    image: mysql:8.0
    secrets:
      - mysql_root_password
      - mysql_password
    environment:
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/mysql_root_password
      MYSQL_PASSWORD_FILE: /run/secrets/mysql_password
      MYSQL_USER: wordpress
      MYSQL_DATABASE: wordpress
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:latest
    depends_on:
      - db
    ports:
      - "8080:80"
    secrets:
      - mysql_password
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD_FILE: /run/secrets/mysql_password
      WORDPRESS_DB_NAME: wordpress

volumes:
  db_data:

注意几个关键点:

1. secrets顶层配置:声明用哪些secrets,external: true表示secret已经存在,不是由compose创建的
2. services.db.secrets:指定这个服务要用哪些secrets
3. MYSQL_ROOT_PASSWORD_FILE:MySQL官方镜像支持_FILE后缀的环境变量,会从文件读取密码而不是直接从环境变量

这个_FILE后缀很重要,不是所有镜像都支持。如果镜像不支持,你需要在启动脚本里自己读取文件:

# entrypoint.sh示例
export DB_PASSWORD=$(cat /run/secrets/db_password)
# 然后启动你的应用

第五步:部署

docker stack deploy -c docker-compose.yml myapp

注意这里用的是docker stack deploy,不是docker-compose up。Swarm mode下要用stack命令。

第六步:验证

进入MySQL容器检查secret是否被正确挂载:

docker exec -it <容器ID> sh
ls -la /run/secrets/

你会看到:

total 8
-r--r--r-- 1 root root 18 Dec 18 10:00 mysql_password
-r--r--r-- 1 root root 18 Dec 18 10:00 mysql_root_password

试试读取:

cat /run/secrets/mysql_root_password

密码出来了。但关键是:这个密码只存在于内存中,不会被写入磁盘,不会出现在环境变量里。

验证docker inspect看不到密码:

docker inspect <容器ID> | grep -i password

你会发现,输出里只有MYSQL_ROOT_PASSWORD_FILE=/run/secrets/mysql_root_password这样的路径,看不到密码本身。

这就是Docker Secrets的威力——密码依然可以被容器内的应用读取,但外部拿不到明文。

Docker Secrets的限制与替代方案

说实话,Docker Secrets不是完美的。主要有这几个限制:

限制1:必须在Swarm模式

这个最让人头疼。如果你只是本地开发,单机跑容器,需要先docker swarm init才能用secrets。虽然单机也能开Swarm,但总感觉有点杀鸡用牛刀。

而且一旦开了Swarm,就得用docker stack deploy,不能用熟悉的docker-compose up了。命令习惯得改。

限制2:secret创建后不能修改

Docker Secrets一旦创建,内容就是只读的。如果密码要改,只能删了重建:

docker secret rm mysql_password
echo "NewPassword789" | docker secret create mysql_password -

然后还得更新使用这个secret的所有服务:

docker service update --secret-rm mysql_password --secret-add mysql_password myapp_db

挺麻烦的。不像环境变量,改完直接重启容器就行。

限制3:不适用于独立容器

如果你用docker run直接启动容器,没法用Docker Secrets。必须是通过docker service create或docker stack部署的服务才行。

这对很多快速测试的场景不友好。我有时候就想临时起个数据库容器试试,结果发现还得整一套Swarm的流程。

单机开发的替代方案:docker-compose file secrets

好在docker-compose有个变通办法——file secrets。它不需要Swarm模式,直接把本地文件挂载成secret。

配置大概这样:

version: '3.8'

secrets:
  db_password:
    file: ./secrets/db_password.txt

services:
  db:
    image: mysql:8.0
    secrets:
      - db_password
    environment:
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_password

然后创建本地密码文件:

mkdir secrets
echo "MyPassword123" > secrets/db_password.txt

注意:一定要把secrets/目录加到.gitignore!

这个方案的安全性比环境变量好,至少密码不会出现在docker inspect里,也不会被打包进镜像。但比不上真正的Docker Secrets,因为:

• 密码文件还是明文存在本地磁盘
• 没有加密传输
• 没有集中管理

不过对于本地开发环境,其实够用了。真正的生产环境,还是老老实实用Swarm或者Kubernetes吧。

进阶技巧

用熟了基础操作,再说几个实用的小技巧。

技巧1:自定义secret挂载路径

默认secret挂载在/run/secrets/<secret_name>,但你可以自定义路径和文件名:

services:
  myapp:
    image: myapp:latest
    secrets:
      - source: db_password
        target: /app/config/database.pwd
        mode: 0400

这里mode: 0400设置了文件权限(只有owner可读),更安全一些。

技巧2:多环境管理

开发、测试、生产环境用不同的密码,但secret名字保持一致:

# 生产环境
docker secret create db_password prod_password.txt

# 测试环境 (另一个Swarm集群)
docker secret create db_password test_password.txt

应用代码只管读/run/secrets/db_password,不用关心具体值。这样代码可以完全一致,只是部署到不同环境的集群而已。

技巧3:secret轮换

定期更换密码是好习惯。Docker的secret轮换稍微有点绕,但也不难:

# 1. 创建新密码
echo "NewPassword" | docker secret create db_password_v2 -

# 2. 更新服务,添加新secret,移除旧secret
docker service update \
  --secret-rm db_password \
  --secret-add source=db_password_v2,target=/run/secrets/db_password \
  myapp_db

# 3. 确认服务正常后,删除旧secret
docker secret rm db_password

注意这里的技巧:新secret名字是db_password_v2,但通过target参数,挂载路径还是/run/secrets/db_password。这样应用不需要改代码。

技巧4:从stdin创建secret

不想在磁盘留痕迹?直接从标准输入创建:

echo "MySecretPassword" | docker secret create db_password -

最后那个-表示从stdin读取。这样连临时文件都不用创建。

或者更安全,手动输入(不会留在shell历史里):

docker secret create db_password -
# 然后粘贴密码,按Ctrl+D结束

其他密钥管理工具对比

四种工具的对比矩阵

Docker Secrets不是唯一的选择。根据项目规模和基础设施,你可能需要其他工具。我整理了个对比表:

简单说:

• 小项目,Docker Swarm → Docker Secrets就够了,免费简单
• Kubernetes生产 → 先用K8s Secrets,配合External Secrets Operator对接外部Vault
• 大厂,多云,高安全要求 → 上Vault,一次性投入,长期受益
• AWS全家桶 → Secrets Manager最省心,和RDS、Lambda配合很爽

没有最好的工具,只有最合适的。我自己的选择路径是:一开始小项目用docker-compose file secrets,团队扩大后上了Docker Swarm + Docker Secrets,现在公司迁到K8s,正在评估要不要引入Vault。

每次迁移都有成本,但安全性确实是逐步提升的。

选择建议

具体点说,怎么选?我给几个决策参考:

如果你是…

个人开发者/小型项目:

• 本地开发:docker-compose file secrets就够了
• 有VPS部署几个服务:Docker Swarm + Docker Secrets
• 预算有限,不想折腾:别上Vault,太重了

创业公司(10-50人):

• 用Docker:Docker Secrets
• 用K8s:K8s Secrets + External Secrets Operator(渐进式,以后能无缝迁移到Vault)
• 全在AWS:直接Secrets Manager,省心

大厂/企业:

• 多云环境:Vault几乎是唯一选择
• 需要审计合规:Vault
• 有专门的安全团队:Vault
• 预算充足,不在乎学习成本:Vault

决策树简化版:

你用K8s吗?
 └─ 是 → 用K8s Secrets,需要高级功能上Vault
 └─ 否 → 用Docker Swarm吗?
      └─ 是 → Docker Secrets
      └─ 否 → 在AWS吗?
           └─ 是 → AWS Secrets Manager
           └─ 否 → docker-compose file secrets(开发) / Vault(生产)

实际案例

说两个我知道的真实选择路径:

案例1:创业公司的演进

朋友的公司做SaaS,起初5个人,服务全Docker部署在单台VPS。一开始用docker-compose + file secrets,密码文件存在服务器上,手动管理。

6个月后拿到天使轮,团队扩到15人,服务拆成了微服务架构。这时候上了Docker Swarm,迁移到Docker Secrets。主要是觉得管理方便了——不用每个服务器去放密码文件,secrets在Swarm集群里集中管理。

又过了一年,A轮后迁到K8s(公司招了DevOps),开始用K8s Secrets。但同时引入了AWS RDS、S3等服务,AWS相关的凭证用Secrets Manager管理,K8s里的secret用External Secrets Operator从Secrets Manager同步。

现在他们在评估要不要统一迁移到Vault,因为多云战略(考虑GCP做备份),Secrets Manager绑定AWS不太合适了。

看到了吗?安全架构是随着业务演进的,没必要一开始就上最复杂的方案。

案例2:传统企业的一步到位

另一个朋友在银行做技术,他们去年做容器化改造。因为是金融行业,合规要求严格,一开始就直接上了Vault。

虽然学习曲线陡,但好处是:

• 审计日志完整,每次密钥访问都有记录
• 支持动态密钥(数据库临时凭证,用完自动过期)
• 可以对接他们现有的LDAP做权限控制

投入了2个人月搭建和培训,但一次性解决了所有密钥管理问题,后续维护成本很低。

不同场景不同选择。小公司折腾Vault可能得不偿失,大企业用Docker Secrets可能不够用。

生产环境最佳实践Checklist

立即行动的安全措施

不管你用不用Docker Secrets,这几件事现在就该做:

✅ 检查Git历史中的敏感信息

# 搜索可能的密码关键词
git log -p -S 'password' -S 'secret' -S 'api_key'

# 检查.env文件是否被提交过
git log --all --full-history -- .env

如果发现了,用git filter-repo或BFG Repo-Cleaner彻底清除历史记录。然后立即更换所有泄露的密码。

✅ 配置.gitignore

# .gitignore
.env
*.env
secrets/
db_password.txt
*_password.txt
*_secret.txt
*.pem
*.key

不要侥幸,一定要加。

✅ 启用GitHub Secret Scanning

如果用GitHub,去仓库设置里开启Security → Secret scanning alerts。一旦你不小心推了密钥,GitHub会自动告警。

免费版仅支持公开仓库,私有仓库需要Pro/Team/Enterprise账号。不过公开仓库更需要,赶紧开。

✅ 更换所有可能泄露的凭证

去盘点一下:

• 数据库密码
• API密钥(AWS/OpenAI/Stripe等)
• JWT secret
• OAuth client secrets
• SSL私钥

能换的都换了。密码泄露后,亡羊补牢也来得及。

Docker Secrets实施步骤

决定用Docker Secrets了?按这个顺序来:

第一步:盘点敏感信息

列个清单,哪些信息是敏感的:

✓ MySQL root密码
✓ 应用数据库密码
✓ Redis密码
✓ JWT签名密钥
✓ 第三方API密钥(支付/短信等)
✓ SSL证书私钥
✓ OAuth client secret

第二步:选择工具

根据前面的对比,选Docker Secrets、K8s Secrets还是Vault。别纠结,先选一个,以后可以迁移。

第三步:创建secrets

# 如果用Docker Swarm
docker swarm init
docker secret create db_password <(echo "密码")
docker secret create api_key <(echo "密钥")

# 如果用docker-compose file secrets
mkdir secrets
echo "密码" > secrets/db_password.txt
echo "密钥" > secrets/api_key.txt
chmod 600 secrets/*

第四步:修改配置文件

把docker-compose.yml里的environment字段改成secrets:

# 改前
services:
  app:
    environment:
      DB_PASSWORD: "hardcoded_password"  # ❌

# 改后
services:
  app:
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password  # ✅

第五步:修改应用代码(如果需要)

如果你的框架不支持_FILE后缀,需要改代码读取文件:

// Node.js示例
const fs = require('fs');
const dbPassword = process.env.DB_PASSWORD_FILE
  ? fs.readFileSync(process.env.DB_PASSWORD_FILE, 'utf8').trim()
  : process.env.DB_PASSWORD;

第六步:测试验证

先在测试环境跑一遍,确认:

• 服务能正常启动
• 能正确读取密码
• docker inspect看不到明文
• 功能正常

第七步:生产部署

没问题了,再部署到生产。保险起见,先保留旧的环境变量配置作为fallback,确认新方案稳定后再删。

持续安全维护

上了Docker Secrets不是一劳永逸,还得持续维护:

定期轮换密钥(建议每90天)

设个日历提醒,每季度换一次密码。尤其是有人离职后,相关的密码一定要换。

监控密钥访问日志

如果用Vault,记得定期查看audit日志。看看有没有异常的访问模式。

Docker Secrets和K8s Secrets默认没有审计日志,这是个缺点。如果需要审计,得配合其他工具(比如Falco)。

最小权限原则

别让所有服务都能访问所有secrets。每个服务只给它需要的:

services:
  frontend:
    secrets:
      - api_key  # 前端只需要API key

  backend:
    secrets:
      - db_password  # 后端需要数据库密码
      - api_key

用密钥扫描工具

集成到CI/CD:

• trufflehog:扫描Git历史
• git-secrets:防止提交敏感信息
• gitleaks:检测代码中的密钥

在pre-commit hook里跑一遍,能拦住不少误提交。

避免踩坑的5个注意事项

最后,说几个常见的坑:

1. 不要用ARG传递敏感信息

# ❌ 错误
ARG DB_PASSWORD=secret
ENV DATABASE_URL=postgres://user:${DB_PASSWORD}@db/myapp

ARG会被保留在镜像构建历史里,docker history能看到。

2. 不要把secrets打印到stdout

# ❌ 错误
password = open('/run/secrets/db_password').read()
print(f"Using password: {password}")  # 会进docker logs!

日志系统会捕获所有stdout输出。密码一旦进日志,就很难删干净了。

3. 不要用同一个secret横跨多个环境

开发、测试、生产环境的密码要分离。别图省事用同一个,万一测试环境泄露了,生产也遭殃。

4. 不要在容器内复制secret到其他路径

# ❌ 错误
cp /run/secrets/db_password /app/config/password.txt

/run/secrets是tmpfs,内存文件系统,容器停了就没了。你复制到其他路径,可能会写入磁盘,反而不安全。

直接从/run/secrets读就行。

5. 不要忘记监控secret的过期和轮换

如果用了有过期时间的动态密钥(Vault支持),得配置好自动续期或轮换的机制。别等到半夜密码过期了,服务全挂了才发现。

结论

说了这么多,其实核心就一句话:别把密码放在能被看到的地方。

环境变量看起来方便,但docker inspect一查就全暴露了。Dockerfile里的ENV指令更危险,会永久保留在镜像层里。很多安全事故,就是因为这些”图方便”的小疏忽。

Docker Secrets不是完美的——需要Swarm模式,不能修改,单机开发不友好。但它至少解决了核心问题:密码加密存储、加密传输、不出现在环境变量和镜像里。对于Docker Swarm集群,它是最简单直接的方案。

如果你用Kubernetes,那就K8s Secrets;如果是企业级需求,可以考虑Vault;如果全在AWS,Secrets Manager也不错。没有最好的工具,只有最合适的。

关键是要行动起来。今天就去检查一下:

• 你的Git历史里有没有密码?
• .env文件加.gitignore了吗?
• docker inspect能看到你的密码吗?

如果答案是”有”、“没有”、“能”,那就该花点时间改改了。不需要一步到位上Vault,哪怕先把环境变量改成file secrets,也比现在安全。

安全是个持续的过程,不是一次性的配置。定期轮换密码,监控异常访问,用扫描工具检查代码——这些习惯比工具本身更重要。

最后,分享给你的团队吧。密钥管理不是某一个人的事,是整个团队的共同责任。统一标准,定期review,才能真正降低风险。

祝好,别再被凌晨3点的告警吵醒了。

参考资源:

• Docker官方文档 - Manage sensitive data with Docker secrets
• HashiCorp Vault官方文档
• AWS Secrets Manager
• trufflehog - Git密钥扫描工具

20 分钟阅读 · 发布于: 2025年12月18日 · 修改于: 2025年12月26日

Easton

技术开发