代码所用凭据存储的最佳实践及加密方案咨询

云原生阿岚

2026-5-19

关于自动化脚本中密码存储的安全性分析与实践建议

嘿，这个场景在运维自动化里太常见了，咱们来聊聊现有方案和加密方案的优劣势，以及怎么落地更安全的方案：

先说说你当前的方案

你现在用仅root可读的pwds.txt存储密码，这个方案本身已经有不错的基础安全性：

Linux的文件权限机制下，chmod 600+chown root:root的文件，非root用户连读取权限都没有，只要权限配置没出错，普通用户根本碰不到密码。
但它的风险点在于：如果攻击者拿到了root权限（比如通过漏洞提权、恶意进程等），密码会直接暴露；另外如果不小心误改了文件权限（比如chmod 644），也会瞬间把密码暴露给所有用户。

加密存储密码确实能提升安全性，但核心难点是密钥的存储位置：

如果把密钥也存在某个仅root可读的文件里，其实和原方案的风险层级差不多——拿到root权限的攻击者照样能拿到密钥，解密出密码。这种情况下加密只是多了一层步骤，没本质提升安全性。
真正有价值的加密方案，是让密钥不落地存储：
- 比如用Linux内核密钥环（keyctl工具）：把密钥存在内存里的密钥环中，脚本运行时通过keyctl get命令获取密钥来解密。密钥不会写到磁盘，系统重启后就会消失，攻击者即使拿到root权限，密钥不在内存的话也无法解密。
- 或者用GPG加密：用root用户的GPG密钥对pwds.txt加密，加密后的文件可以随便放（权限甚至可以设为644），脚本运行时用gpg --decrypt encrypted_pwds.txt读取，因为只有root用户能访问自己的GPG私钥，其他人拿到加密文件也解不开。

如果你的系统root权限管控很严格（比如只有少数可信人员能提权，系统防护到位），可以先加固现有方案：

确保pwds.txt的权限严格为chmod 600，属主属组都是root：chown root:root /path/to/pwds.txt && chmod 600 /path/to/pwds.txt
脚本本身也要设置权限为chmod 700，只有root能执行，防止被篡改：chown root:root /path/to/your_script.sh && chmod 700 /path/to/your_script.sh
脚本里读取密码后，避免用echo等命令打印密码，防止被进程列表、系统日志捕获。

如果要升级到加密方案，推荐两种实用的方式：

先把密钥添加到root的内核密钥环：
```
keyctl add user my_script_key "your_secret_key" @u
```
这条命令会把密钥your_secret_key以my_script_key的名称存在root用户的密钥环里，重启后会消失，需要重新添加（可以加到root的开机脚本里，或者手动加载）。

脚本里读取密钥并解密密码（假设用AES加密）：

# 获取密钥
KEY=$(keyctl get user my_script_key)
# 解密加密后的密码文件
DECRYPTED_PWD=$(openssl enc -aes-256-cbc -d -in /path/to/encrypted_pwds.txt -k "$KEY")

用root用户生成GPG密钥（如果没有的话）：
```
gpg --full-generate-key
```
按提示选择密钥类型、有效期，设置密码（也可以设空密码，但安全性稍低）。
加密你的pwds.txt：
```
gpg --encrypt --recipient your_root_gpg_email /path/to/pwds.txt
```
会生成pwds.txt.gpg加密文件，原pwds.txt可以删除。
脚本里解密读取：
```
DECRYPTED_PWD=$(gpg --decrypt /path/to/pwds.txt.gpg)
```
如果GPG密钥设了密码，可配合gpg-agent让root用户的密钥环记住密码，避免手动输入影响自动化。

尽量缩小脚本的权限范围：不要让整个脚本以root运行，而是用sudo给单个命令授权。比如在sudoers里配置允许普通用户以root身份执行特定的mysql命令，这样脚本即使被攻破，权限也更小。
定期轮换密码和密钥：不管用哪种方案，定期轮换密码和密钥能降低泄露后的风险。

内容的提问来源于stack exchange，提问作者sel