笙亿网络策划

Django的SECRET_KEY在部署时应该怎么保密管理

约 6 分钟读完 2 阅
文章导读
刚接触 Django 部署的开发者，最容易犯的一个错误就是把 SECRET_KEY 直接写在 settings.py 里，然后提交到代码仓库。SECRET_KEY 是 Django 安全签名的核心凭据，用于会话、CSRF 保护、密码重置令牌等场景。一旦泄露，攻击者可以伪造签名、窃取会话、甚至执行远程代码执行（取决于具体利用方式）。在部署环境中，绝对不要将 SECRET_KEY 硬编码在 setti
📋 目录
  1. Ⅰ 为什么 SECRET_KEY 不能写在 settings.py 里
  2. Ⅱ 最推荐的方式：操作系统环境变量
  3. Ⅲ 备选方案：文件存储
  4. Ⅳ 几个容易踩的坑
  5. Ⅴ 部署后确认密钥来源
  6. Ⅵ 轮换密钥的影响与操作
A A

为什么 SECRET_KEY 不能写在 settings.py 里

刚接触 Django 部署的开发者，最容易犯的一个错误就是把 SECRET_KEY 直接写在 settings.py 里，然后提交到代码仓库。SECRET_KEY 是 Django 安全签名的核心凭据，用于会话、CSRF 保护、密码重置令牌等场景。一旦泄露，攻击者可以伪造签名、窃取会话、甚至执行远程代码执行（取决于具体利用方式）。在部署环境中，绝对不要将 SECRET_KEY 硬编码在 settings.py 中，否则代码仓库一旦被访问，密钥即刻暴露。正确做法是将密钥移到环境变量或外部文件，确保只有运行应用的进程能读取。这句话不是空话，我见过好几个项目因为截图或 git 历史泄露导致线上被入侵。

最推荐的方式：操作系统环境变量

推荐通过操作系统环境变量注入 SECRET_KEY。在部署服务器上设置环境变量，例如在 Linux 的 /etc/environment 或 .bashrc 中写入 export DJANGO_SECRET_KEY='your-secret-key'。然后在 settings.py 中通过 os.environ.get('DJANGO_SECRET_KEY') 获取。注意：不要在代码中硬编码默认值，否则环境变量未设置时会回退到不安全默认值。建议先判断变量是否存在，若不存在则抛出异常或显式终止启动。我一般这样写：

import os
SECRET_KEY = os.environ['DJANGO_SECRET_KEY']

这样如果环境变量未定义，Django 启动时会直接报错，不会静默使用空值。有些团队喜欢在 settings.py 里写一个默认值方便开发，但一定要确保在部署前被覆盖。我建议用环境变量文件（比如 .env）配合 python-decouple 这类库，但部署服务器的环境变量注入仍然是最终保障。注意：环境变量在进程启动时读取，修改后需要重新启动应用。

Django的SECRET_KEY在部署时应该怎么保密管理

备选方案：文件存储

若因平台限制无法使用环境变量，可将 SECRET_KEY 存入一个单独文件（如 /etc/django_secret_key.txt），并配置严格的文件权限（600 或 400，仅属主可读）。在 settings.py 中使用 open 读取文件内容，注意捕获异常。此方案要求文件路径不在代码仓库内，最好放在 /etc 或 /var/secure 等受保护目录。缺点是密钥随文件存在，若服务器磁盘被访问则可能泄露，需配合文件系统加密等额外措施。我个人不太推荐，因为文件路径本身也是配置项，容易写死或泄露。如果一定要用，建议对文件内容做 Base64 编码或者配合 Django 的密钥管理器。不过多数情况下环境变量更简洁。

几个容易踩的坑

一个常见错误是开发者和运维人员为了方便，将 SECRET_KEY 写死在 settings.py 中，然后通过 .gitignore 忽略该文件。但一旦有人误提交或代码审查遗漏，密钥便落入 git 历史。更隐蔽的是，有人将密钥放在配置管理工具（如 Ansible Vault、HashiCorp Vault）中，但未在部署脚本里正确解密，导致最终运行时仍使用硬编码默认值。检查方法：部署后查看 settings.py 文件中是否仍包含 'django-insecure-' 开头的默认密钥字符串。另外，有些人把密钥写在 Docker 镜像的环境变量里，但镜像层可能被推送到公共仓库，风险更大。正确的 Docker 做法是运行时通过 -e 或 Docker Swarm secrets 注入。

Django的SECRET_KEY在部署时应该怎么保密管理

部署后确认密钥来源

部署后可通过 Django shell 快速确认 SECRET_KEY 来源：运行 python manage.py shell，输入 from django.conf import settings; print(settings.SECRET_KEY)。对比预期密钥。若输出与代码仓库中 settings.py 里的一致（尤其是包含 'django-insecure-' 前缀），说明未正确覆盖，需立即修正。另外，检查进程环境变量：在服务器上执行 echo $DJANGO_SECRET_KEY（假设变量名如此），若不输出任何内容，则环境变量未注入。这个方法很直接，可以作为部署流水线的验证步骤。

Django的SECRET_KEY在部署时应该怎么保密管理

轮换密钥的影响与操作

SECRET_KEY 应定期轮换，操作前需评估影响：旧密钥签发的会话令牌、重置链接、CSRF 令牌将失效，导致用户需重新登录。轮换时，可在 settings.py 中保留旧密钥列表，通过 SECRET_KEY_FALLBACKS 设置（Django 4.1+）支持多个密钥验证。具体做法：生成新密钥替换主 SECRET_KEY，将旧密钥放入 SECRET_KEY_FALLBACKS。注意：旧密钥仍会泄露，务必只保留必要轮换周期（如半年），并在过期后彻底移除。如果不是紧急泄露，建议选择低峰期操作，提前通知用户重新登录。对于 Django 版本低于 4.1 的项目，轮换需要更谨慎，可能需要同时保留旧会话或接受用户重新登录。

最后提醒一点：密钥管理没有万能方案，需要结合你的部署环境（云厂商、容器编排、配置中心等）选择最合适的注入方式。始终记住：密钥只在需要它的进程内存中存在短暂时间，磁盘、代码、日志里都不应该留下明文。