不能直接用os.getenv读取敏感配置，因其仅读取明文环境变量，无法防止Git提交、镜像层残留、日志泄露及运维直连暴露；应采用Fernet加密密文+独立ENCRYPTION_KEY环境变量解密，并严格校验密钥格式与解密异常。
为什么不能直接用 os.getenv 读取敏感配置
因为环境变量本身是明文存储在系统进程环境里的，os.getenv 只是把内存里已有的字符串拿回来，完全不解决泄露问题。真正要防的是：配置文件被提交到 Git、Docker 镜像层残留、日志误打敏感值、运维人员直连服务器时看到 env 输出。
用 cryptography 库做对称加密 + 环境密钥解密
核心思路是：配置值在部署前用密钥加密成字符串，存进环境变量；运行时用同一密钥解密。密钥不写死在代码里，而是通过另一个（更受控的）环境变量传入，比如 ENCRYPTION_KEY。
-
ENCRYPTION_KEY必须是 32 字节的 base64 编码密钥（对应 AES-256），生成方式：secrets.token_urlsafe(32)→ 去掉=→ 截取前 32 字节 - 加密时用
Fernet（cryptography 库提供），它自动处理 nonce 和签名，比裸 AES 安全得多 - 解密失败必须抛异常，不能返回空或默认值，否则会掩盖密钥不匹配或密文损坏问题
from cryptography.fernet import Fernet
import os
<p>def load_encrypted_env(var_name: str) -> str:
encrypted = os.getenv(var_name)
key_b64 = os.getenv("ENCRYPTION_KEY")
if not encrypted or not key_b64:
raise ValueError(f"Missing {var_name} or ENCRYPTION_KEY")
try:
f = Fernet(key_b64.encode())
return f.decrypt(encrypted.encode()).decode()
except Exception as e:
raise ValueError(f"Decryption failed for {var_name}: {e}")</p><h1>使用示例：DB_PASSWORD 加密后存为 ENCRYPTED_DB_PASSWORD</h1><p>db_password = load_encrypted_env("ENCRYPTED_DB_PASSWORD")
如何安全生成和注入加密后的环境变量
本地开发时别手动生成密文——容易出错且密钥管理混乱。应该用脚本统一处理：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 加密命令行工具：用
cryptography写个简单 CLI，输入明文和ENCRYPTION_KEY，输出 base64 密文 - Docker 部署时，密钥通过
--env-file注入，密文通过-e ENCRYPTED_XXX=...注入，两者绝不写在同一文件 - Kubernetes 中，
ENCRYPTION_KEY放Secret，密文放ConfigMap或另一个Secret（但注意：不同 Secret 之间无访问控制隔离） - CI/CD 流水线里禁止 echo 密钥或密文到日志，所有相关步骤加
mask或no-output
常见踩坑点：密钥格式、编码、时序
最常报的错是 ValueError: Invalid token 或 Invalid key，基本都源于这三类：
立即学习“Python免费学习笔记（深入）”；
-
ENCRYPTION_KEY不是合法 Fernet 密钥：必须是 32 字节 URL-safe base64 编码，不能带换行、空格、=，也不能用str.encode()直接转原始字符串 - 密文被 shell 或 YAML 自动截断或转义：比如密文含
+或/，在某些 CI 环境或 .env 文件里会被错误解析，建议全程用单引号包裹并验证长度 - 启动顺序问题：有些框架（如 Django）在模块导入阶段就初始化配置，此时
os.getenv还没被正确设置，导致解密函数拿到空值 —— 解决办法是把解密逻辑推迟到应用实际需要配置时（比如第一次数据库连接）
加密不是银弹。如果攻击者能执行任意代码或拿到完整进程内存，密钥和明文迟早会暴露。重点是抬高横向移动成本，而不是幻想绝对安全。
