API Key 的管理核心不是管理 ENV 文件,而是把密钥从代码里面拿出来,放到运行环境里面。
这样设计的优势在于:
只在服务端使用
按环境、项目、服务进行隔离
可限制、可轮换、可撤销、可审计
真正的 API Key 管理可以看成一套 ,身份、权限、账单、安全、运维体系。
.env 文件是什么
.env通常是存放在本地开发环境的变量
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxx
OPENAI_BASE_URL=https://api.openai.com/v1
OPENAI_MODEL=gpt-4.1-mini
NODE_API_KEY=local-node-secret
APP_ENV=development
LOG_LEVEL=info
.env -> 操作系统/进程环境变量 -> 应用程序读env
.env存放真实值
.env.example存放空值或示例值
APP_ENV=development
NODE_API_KEY=
OPENAI_API_KEY=
OPENAI_BASE_URL=https://api.openai.com/v1
OPENAI_MODEL=
LOCAL_MODEL_BASE_URL=
LOCAL_MODEL_NAME=
.gitignore
.env
.env.*
!.env.example
secrets/
*.pem
*.key
python 读环境变量
pip install python-dotenv
import os
from dotenv import load_dotenv
load_dotenv()
api_key = os.getenv("OPENAI_API_KEY")
model = os.getenv("OPENAI_MODEL", "gpt-4.1-mini")
Docker Compose里优雅写法
my-llm-node/
├── docker-compose.yml
├── secrets/
│ ├── openai_api_key.txt
│ └── node_api_key.txt
└── app/
secrets/openai_api_key.txt:
sk-xxxxxxxxxxxxxxxx
docker-compose.yml
services:
llm-node:
build: .
ports:
- "8000:8000"
environment:
OPENAI_API_KEY_FILE: /run/secrets/openai_api_key
NODE_API_KEY_FILE: /run/secrets/node_api_key
APP_ENV: production
secrets:
- openai_api_key
- node_api_key
secrets:
openai_api_key:
file: ./secrets/openai_api_key.txt
node_api_key:
file: ./secrets/node_api_key.txt
python代码
OPENAI_API_KEY = read_secret("OPENAI_API_KEY")
NODE_API_KEY = read_secret("NODE_API_KEY")
以功能作用域为单位分APIKEY
不要所有人、所有项目共用一个 Key,要分作用域、分功能、分项目来放这个 API Key。
OpenAI Project
│
├── dev-key 低额度,方便调试
├── staging-key 测试环境
├── prod-key 生产服务
└── worker-key 后台任务
防止泄露
当你的账单出现非常异常的时候,你得马上禁用那个 API Key,然后创建新的 API Key,更新到你的配置文件里面。
然后再不要让应用程序去读你的 key,不要打印打到日志中。
最小可行性
- 项目根目录创建.env
- .gitignore忽略.env
- 代码只读环境变量
- 不打印完整的KEY
- 给Key设置预算
- 定期清理Key
总结
- API Key 是账单,是钱,是Token,不是普通配置
- .env 是工具,不是保险柜
- Key 不进代码,不进Git,不进前端,不进日志
- 人、环境、服务,都使用独立的Api Key
- 生产环境优先使用 Docker Secrets
- Key 要设置权限、预算、监控
- Key 要定期轮换、撤销、审计
思维范式Tips
- 边界思维
- 最小暴露思维
- 生命周期思维
- 分层治理思维
- 网关思维
- 可撤销思维
- 配置与秘密分离