文章目录
- 密码、密钥、配置——生产环境里这些到底放哪
- 导入语
- 1 ~> 基础方案：`.env` 文件 + `python-decouple`
- 1.1 `.env` 文件格式
- 1.2 `settings.py` 中使用
- 1.3 `.gitignore` 中必须有的条目
- 2 ~> 进阶方案：`django-environ`——更丰富的环境管理
- 3 ~> 多环境配置——开发、测试、生产三套隔离
- 4 ~> 生产级方案——Kubernetes Secrets / AWS Parameter Store
- 5 ~> `SECRET_KEY` 的生成与保护
- 思考 && 总结
- 结尾
密码、密钥、配置——生产环境里这些到底放哪
📖文章简介：Django 项目从本地开发推到生产环境，第一个让你手足无措的问题：“数据库密码放哪？”——settings.py里写死了？推到 GitHub 仓库别人随便看。环境变量？服务器上手动export？写了也容易丢。本文从.env文件讲起，逐步覆盖django-environ的完整用法、python-decouple的类型转换、以及生产环境中密钥管理的分层策略——开发、测试、生产三套配置如何隔离而不出错。穿插真实事故——实习生把.env推到了公共仓库的 GitHub，被爬虫扫描到后数据库被清空。
🎬 个人主页：源码骑士
❄专栏传送门：《Android开发基础》《python基础课程》
⭐️热衷从源码视角拆解技术底层原理，将复杂架构讲得通俗易懂
🎬 源码骑士的简介：
5年Android Framework系统开发经验，曾主导多项系统级性能优化专项
技术栈覆盖Android系统全链路（Binder/Handler/AMS/WMS/启动流程）及Java后端全家桶（Spring + MyBatis + Redis + Oracle）
累计产出原创技术文章100+篇，文章以源码拆解为特色，被读者评价为"看一篇胜过啃一周文档"
导入语
“数据库密码放哪”——这是 Python Web 开发中最老生常谈但也出错最多的问题。
2019 年，公司一个实习生在做 Django 项目，把.env文件（包含数据库密码和 SECRET_KEY）连同代码一起git push到了 GitHub 公共仓库。30 分钟后，GitHub 的自动扫描工具检测到 AWS 密钥泄露，自动通知了我们——但太晚了，爬虫脚本已经用那个密码把测试库的数据清空了。幸运的是那只是测试库。从那以后，我立了一条铁律——.env必须在.gitignore中第一行声明。
1 ~> 基础方案：.env文件 +python-decouple
1.1.env文件格式
# .env——不要提交到 Git！SECRET_KEY=django-insecure-abc123xyzDB_NAME=myprojectDB_USER=adminDB_PASSWORD=SuperSecret123DB_HOST=localhostDB_PORT=3306DEBUG=False1.2settings.py中使用
# settings.pyfromdecoupleimportconfig,Csv SECRET_KEY=config("SECRET_KEY")DEBUG=config("DEBUG",default=False,cast=bool)DATABASES={"default":{"ENGINE":"django.db.backends.mysql","NAME":config("DB_NAME"),"USER":config("DB_USER"),"PASSWORD":config("DB_PASSWORD"),"HOST":config("DB_HOST"),"PORT":config("DB_PORT",cast=int),}}1.3.gitignore中必须有的条目
# 第一行——没有商量的余地 .env # 也可以加这些 *.local secrets.py config/local.py2 ~> 进阶方案：django-environ——更丰富的环境管理
# settings.pyimportenviron env=environ.Env(DEBUG=(bool,False)# 默认值 + 类型转换)# 读取 .env 文件environ.Env.read_env(os.path.join(BASE_DIR,".env"))SECRET_KEY=env("SECRET_KEY")DEBUG=env("DEBUG")DATABASES={"default":env.db(),# 一键解析 DATABASE_URL}CACHES={"default":env.cache(),# 一键解析 CACHE_URL}3 ~> 多环境配置——开发、测试、生产三套隔离
myproject/ ├─ settings/ │ ├─ __init__.py │ ├─ base.py# 所有环境共用的配置│ ├─ development.py# from .base import * + 覆盖 Dev 专用配置│ ├─ staging.py# 测试环境│ └─ production.py# 生产环境使用方式：
# 开发环境exportDJANGO_SETTINGS_MODULE=myproject.settings.development python manage.py runserver# 生产环境exportDJANGO_SETTINGS_MODULE=myproject.settings.production gunicorn myproject.wsgi4 ~> 生产级方案——Kubernetes Secrets / AWS Parameter Store
| 级别 | 方案 | 适合场景 |
|---|---|---|
| 个人项目 | .env文件 +.gitignore | ✅ 足够 |
| 小团队 | django-environ+ 多环境配置 | ✅ 推荐 |
| 生产集群 | Kubernetes Secrets | ✅ 企业管理级别 |
| 云原生 | AWS Parameter Store / Azure Key Vault | ✅ 最高安全级别 |
5 ~>SECRET_KEY的生成与保护
fromdjango.core.management.utilsimportget_random_secret_keyprint(get_random_secret_key())# 输出类似：django-insecure-abc123...SECRET_KEY用于签名 session、CSRF token、密码重置链接。泄漏后攻击者可以伪造任意用户的 session——等于站点的身份系统全毁了。
思考 && 总结
密钥管理的三层安全：
.env不在 Git 中——这是最低安全底线。- 生产
.env和开发.env分开——别让开发机上的调试密码和生产库相同。 - 密钥轮换——敏感服务的密钥建议周期性更换。对于生产环境考虑 KMS 或 Kubernetes Secrets。
结尾
密钥管理讲完了。感谢阅读！
源码骑士 — 源码级拆解，从底层看透技术
👀关注：跟博主一起从源码视角深耕底层原理
❤️点赞：让优质内容被更多人看见
⭐收藏：核心知识点存好，随用随查
💬评论：分享你的经验或疑问，一起交流
🔄一键四连：别忘了给博主一键四连！
🗡️寄语：一行.env进.gitignore，能省掉整个公司一夜的灾难。
结语：密码管理是安全的最低门槛。下篇进入 Docker——Django 项目的容器化部署。一键四连！
