ReaderMX.
Python技术迷

Python中如何优雅的实现代码与敏感信息分离？

Ppython约 8 分钟

昨天晚上十一点多，我正准备关电脑回家，我们组那个小李在工位后面喊我一句：“东哥，我可能把生产库密码传到 GitHub 了…咋办啊？”

我当时整个人一下就清醒了，困意全没，心里只有一个想法：完了，这波要背锅。

其实你们肯定也遇到过类似的事：本地调试图省事，把数据库密码、Redis 密码、第三方支付的 key 全写在代码里，跑是好跑了，过两天一提交、一开源，或者日志一打，全世界都知道你家的密码了。

所以今天想聊的就是——用 Python 怎么比较优雅地做到：代码归代码，密码密钥这些敏感信息，统统滚出代码。

我慢慢说，别急。

一、先搞清楚：到底什么叫“分离”

你可以先想象一个最糟糕的写法：

# db.py  ——— 典型的灾难现场
import mysql.connector
conn = mysql.connector.connect(
    host="127.0.0.1",
    user="root",
    password="SuperSecret123!",  # 生产密码硬编码
    database="prod_db",
)

这几个问题一眼就能看出来：

  1. 只要代码泄露，密码直接裸奔
  2. 换环境巨麻烦，测试、预发布、生产的配置都得改代码
  3. 想轮换密码（比如安全部要求一个季度换一次）？再发版一遍

所谓“代码与敏感信息分离”，其实就两件事：

  • 业务逻辑的代码里，不出现具体的密码、token、密钥、账号这类东西
  • 真正的敏感数据放在外部载体里：配置文件、环境变量、密钥服务里，通过统一的配置层读进来

目标很朴素：代码可以随便看，配置谁都看不着。

二、最常见的一步升级：把敏感信息挪到配置文件

很多团队第一步都是这么干：搞个 config.yaml / config.toml / settings.json 之类的。

比如来一套简单的 YAML：

config.yaml：

app:
debug:true
database:
host:127.0.0.1
port:3306
user:app_user
password:"change-me"# 注意：这里只是占位，不是真实密码
name:app_db

Python 里这么读：

# settings.py
import pathlib
import yaml
BASE_DIR = pathlib.Path(__file__).resolve().parent
defload_config(path: str | None = None) -> dict:
if path isNone:
        path = BASE_DIR / "config.yaml"
with open(path, "r", encoding="utf-8") as f:
return yaml.safe_load(f)
config = load_config()
db_cfg = config["database"]
defget_db_dsn() -> str:
return (
f"mysql+pymysql://{db_cfg['user']}:{db_cfg['password']}"
f"@{db_cfg['host']}:{db_cfg['port']}/{db_cfg['name']}"
    )

这样做，起码有几个好处：

  • 业务代码里面基本看不到密码这些东西
  • 换环境直接换配置文件，不动代码
  • 配置还能被运维、人肉修改，不需要你改代码发版

但这里有个巨大的坑：千万别把真实的 config.yaml 提交到 Git 仓库里。

比较靠谱的做法是：

  1. 仓库里只放一份模板：config.example.yaml

    app:
    debug:false
    database:
    host:127.0.0.1
    port:3306
    user:your_db_user
    password:"your-secure-password-here"
    name:your_db_name

  2. 真正的 config.yaml 写到 .gitignore 里

    config.yaml

  3. 新人入项，照着 config.example.yaml 拷贝一份，自己填真实值

这样至少能保证：代码库本身是干净的，里面没有真实密码。

不过，只靠配置文件其实还不够，等你有了多套环境之后，很快就会乱成一锅粥：config.dev.yaml / config.test.yaml / config.prod.yaml，一不小心就用错。

三、再走一步：用环境变量做“最后一层”

到这一步，我们可以把规则再拉严一点：真正的敏感信息用环境变量，配置文件里只放默认值或者不那么敏感的东西。

一个常见组合是：配置文件 + 环境变量覆盖。

先来个小工具函数：

# config_loader.py
import os
from typing import Any
import yaml
defload_yaml_config(path: str) -> dict[str, Any]:
with open(path, "r", encoding="utf-8") as f:
return yaml.safe_load(f)
defenv_or_default(key: str, default: Any | None = None) -> Any:
    value = os.getenv(key)
return value if value isnotNoneelse default

再来个简单的“配置对象”：

# settings.py
import pathlib
from dataclasses import dataclass
from config_loader import load_yaml_config, env_or_default
BASE_DIR = pathlib.Path(__file__).resolve().parent
_raw_cfg = load_yaml_config(BASE_DIR / "config.yaml")
@dataclass
classDatabaseSettings:
    host: str = env_or_default("DB_HOST", _raw_cfg["database"]["host"])
    port: int = int(env_or_default("DB_PORT", _raw_cfg["database"]["port"]))
    user: str = env_or_default("DB_USER", _raw_cfg["database"]["user"])
    password: str = env_or_default("DB_PASSWORD", _raw_cfg["database"]["password"])
    name: str = env_or_default("DB_NAME", _raw_cfg["database"]["name"])
@dataclass
classSettings:
    debug: bool = bool(env_or_default("APP_DEBUG", _raw_cfg["app"]["debug"]))
    database: DatabaseSettings = DatabaseSettings()
settings = Settings()

业务代码里就可以很自然地用：

# db.py
from sqlalchemy import create_engine
from settings import settings
db = settings.database
dsn = (
f"mysql+pymysql://{db.user}:{db.password}"
f"@{db.host}:{db.port}/{db.name}"
)
engine = create_engine(dsn, echo=settings.debug)

然后在不同环境里面，只要设置环境变量就行，比如 Linux 服务器上：

export DB_HOST=10.0.0.10
export DB_USER=prod_user
export DB_PASSWORD='really-secure-password'
export DB_NAME=prod_db
export APP_DEBUG=false

这样一来：

  • 仓库里没有真实密码
  • 配置文件里也可以只放“开发默认值”
  • 线上密码谁管？运维管、K8s 管、Docker Compose 管，总之跟代码没关系

四、开发环境怎么偷懒？用 .env 也能优雅

说实话，本地每次都手动 export 一堆变量，谁都懒得搞。这个时候 .env 就派上用场了。

你可以在项目根目录放一个 .env 文件（同样写进 .gitignore）：

.env：

APP_DEBUG=true
DB_HOST=127.0.0.1
DB_PORT=3306
DB_USER=root
DB_PASSWORD=local-dev-password
DB_NAME=demo_db

Python 里用 python-dotenv 这个库，自动帮你把 .env 加载成环境变量：

pip install python-dotenv

然后在你的入口文件里加一句：

# main.py
from dotenv import load_dotenv
# 尽量在 import 其他模块之前调用
load_dotenv()
from settings import settings  # noqa: E402
from fastapi import FastAPI
app = FastAPI()
@app.get("/ping")
defping():
return {"db": settings.database.host, "debug": settings.debug}

这时候你在本地跑项目，.env 里的值就自动生效了。

不同环境你甚至可以搞多份：

  • .env.dev
  • .env.test
  • .env.prod（这个一般只放在服务器上，不放仓库）

然后写个简单的启动脚本，根据环境加载不同 .env：

# bootstrap.py
import os
from dotenv import load_dotenv
env = os.getenv("APP_ENV", "dev")  # dev / test / prod
env_file = {
"dev": ".env.dev",
"test": ".env.test",
"prod": ".env.prod",
}.get(env, ".env")
load_dotenv(dotenv_path=env_file, override=True)
# 真正的应用入口
from main import app  # noqa: E402

这样你本地只要：

export APP_ENV=dev  # 或 test / prod
uvicorn bootstrap:app --reload

整个配置切换逻辑就统一了，不用在代码里到处写 if ENV == "prod": ... 这种东西。

五、再上一个档次：用“配置中心 / 密钥服务”

等系统稍微大一点，你可能会听到运维同事说：用一下 K8s Secret / Vault / 云厂商的密钥管理（SM / KMS）之类的。

思路其实也很简单：密码不落盘，按需取一次，用完就扔，最好还带自动轮换。

在 Python 里你可以留一个“抽象层”，把获取密钥封装起来，不让业务感知来源：

# secrets_provider.py
from abc import ABC, abstractmethod
import os
classSecretsProvider(ABC):
    @abstractmethod
defget(self, key: str) -> str:
raise NotImplementedError
classEnvSecretsProvider(SecretsProvider):
defget(self, key: str) -> str:
        value = os.getenv(key)
if value isNone:
raise KeyError(f"missing secret: {key}")
return value
# 以后可以加 VaultSecretsProvider / AwsSecretsProvider 等

配置里只需要指定一下用哪个 provider：

# settings_secrets_example.py
from secrets_provider import EnvSecretsProvider
secrets = EnvSecretsProvider()
DB_PASSWORD = secrets.get("DB_PASSWORD")
REDIS_PASSWORD = secrets.get("REDIS_PASSWORD")

后面你要把秘密从环境变量搬到 Vault，只要改 provider 的实现，不用动上层业务代码。

这也是“分离”的另一层含义：代码跟“怎么拿到秘密”这件事也要解耦。

六、别踩的几个坑，说说人话

这个话题讲多了难免有点抽象，我顺手把平时看到的几个坑跟你说一下，避免你也踩：

  1. 日志里把配置打印出来 很多人调试的时候喜欢 print(settings.__dict__)，然后日志被收集到 ELK，一堆密码就这么进了搜索系统。 做配置对象的时候，记得对敏感字段做一下掩码，或者在 __repr__ 里干脆别打印出来。

  2. 临时硬编码忘删 本地调试的时候写了个：

    settings.database.password = "临时密码"

    结果一合代码，直接上生产。 这种操作尽量别干，实在要改，就改 .env 或者环境变量。

  3. 样例配置写得太“真实” 比如在 config.example.yaml 里写：

    password:"123456"

    新人入项一看：哦，原来默认密码就是 123456，然后真的这么用。 建议直接写成明显的占位符，比如 "PLEASE_CHANGE_ME"，逼着大家改。

  4. 权限放太宽 分离只是第一步，真正落到服务器上，还要配合权限：

    否则搞得再花哨，结果是所有人都能看，那就没啥意义。

  • .env 文件权限设成只有服务用户可读
  • K8s Secret 只挂给需要的 Pod
  • 云厂商的密钥服务，只给对应服务的角色访问

  • 单元测试乱读真实配置 测试的时候，建议搞一套专门的测试配置，比如 config.test.yaml，里面放的是测试数据库、测试 redis，不要复用开发/生产的配置，更不要复用真实密码。 不然有一天你在本地跑测试，把生产库数据删了，那又是一个事故故事。

    • 其实你回头看一眼，会发现所谓“优雅地分离代码和敏感信息”，也没什么玄学，无非就是：

    • 不在 Python 源码里写死密码
    • 敏感信息出现在受控的地方：环境变量、只读配置、密钥服务
    • 用一个统一的配置层/配置对象，把这些东西都集中起来管理

    做到这几条，哪怕哪天仓库不小心被人看了，你也能比较淡定： “看吧，里面只有一堆 DB_PASSWORD 的占位符，真密码你拿不到。”

    等你哪天晚上十一点，也被同事喊起来说“我好像把密码传上去了”的时候，你就会感谢现在多花的这一点点心思。

    KEEP THE THREAD GOING

    更多来源文章