在 Systemd 服务单元中安全管理环境变量
Systemd 作为现代 Linux 发行版的主要系统和服务管理器，依靠服务单元文件（.service）来定义应用程序的启动、停止和维护方式。配置任何现代应用程序的一个关键方面是注入配置设置、路径，以及最重要的是，诸如 API 密钥或数据库凭据等敏感秘密信息。
对这些环境变量的不当管理可能导致安全漏洞、调试困难以及不可移植的配置。本指南将详细介绍 Systemd 的相关指令——Environment 和 EnvironmentFile——并演示如何安全地使用即时配置（drop-in configuration）文件来处理敏感数据，以确保关注点分离和健壮的安全实践。
环境变量在 Systemd 中的作用
环境变量提供了一种直接的机制来配置服务，而无需修改其二进制文件或代码。当 Systemd 启动服务时，它会构建一个完整的环境（包括必要的 PATH、用户/组变量等），并在执行 ExecStart 命令之前注入单元文件中定义的任何变量。
Systemd 在单元文件的 [Service] 部分提供了两个主要的指令来管理这些变量。
1. 直接定义：Environment 指令
这种方法允许您直接在 Systemd 单元文件中定义变量。这适用于不敏感且很少更改的配置参数。
用法与语法
Environment 指令接受一个以空格分隔的变量赋值列表，格式为 "KEY=VALUE"。
# /etc/systemd/system/my-app.service
[Unit]
Description=我的应用程序服务
[Service]
User=myuser
WorkingDirectory=/opt/my-app
# 直接在单元文件中定义变量
Environment="APP_PORT=8080" "NODE_ENV=production"
ExecStart=/usr/local/bin/my-app --start
[Install]
WantedBy=multi-user.target
局限性与安全性
尽管方便，但 Environment 指令绝不应用于敏感信息（秘密、密码、API 密钥）。单元文件通常存储在配置管理系统中，或位于对各种用户可访问的目录中（即使是只读，也可能根据配置被非 root 用户查看）。直接硬编码秘密信息会损害安全原则。
2. 外部配置：EnvironmentFile 指令
对于复杂配置、动态变量或敏感数据，从外部文件加载变量是首选方法。这允许您独立于主单元文件管理变量文件的权限。
用法与语法
EnvironmentFile 指令接受一个配置文件的绝对路径。Systemd 逐行读取此文件，将每行视为一个潜在的 KEY=VALUE 赋值。
[Service]
# 从外部文件加载变量
EnvironmentFile=/etc/config/my-app-settings.conf
ExecStart=/usr/local/bin/my-app --start
环境变量文件格式
外部文件必须遵循简单的类 shell 格式：
- 以
#开头的行被视为注释。 - 以空变量赋值（
VAR=）开头的行将清除先前设置的变量。 - 变量定义为
KEY=VALUE。 - 支持对值进行引用（
KEY="VALUE WITH SPACES"）。
# /etc/config/my-app-settings.conf
# 非敏感变量
MAX_WORKERS=4
LOG_LEVEL=INFO
# 敏感变量（需要严格的文件权限）
DB_PASSWORD=SecureRandomString12345
处理缺失文件
默认情况下，如果 EnvironmentFile 指定的文件不存在，Systemd 将导致服务启动失败。如果环境变量文件是可选的，您可以在文件路径前加上连字符（-）：
EnvironmentFile=-/etc/config/optional-settings.conf
如果文件路径前缀为 -，Systemd 将忽略因文件不存在而导致的错误。
最佳实践：使用即时单元处理敏感数据
修改核心单元文件（例如，/usr/lib/systemd/system/my-app.service）通常不被推荐，特别是当该文件由包管理器管理时。相反，应使用即时单元文件（drop-in unit files）来应用配置覆盖或添加。
这种做法在处理敏感环境变量时至关重要，因为它允许您将标准服务配置与本地秘密文件路径分离。
即时配置的逐步指南
1. 定位/创建即时目录
对于名为 my-app.service 的服务，即时目录必须命名为 my-app.service.d/ 并位于 /etc/systemd/system/ 层次结构中。
sudo mkdir -p /etc/systemd/system/my-app.service.d/
2. 创建配置覆盖文件
在即时目录中创建一个文件（例如 secrets.conf）。该文件只需要 [Service] 部分以及您希望覆盖或添加的特定指令。
# /etc/systemd/system/my-app.service.d/secrets.conf
[Service]
# 加载安全的凭据文件
EnvironmentFile=/etc/secrets/my-app-credentials.env
3. 保护外部环境变量文件
这是最关键的安全步骤。确保包含秘密信息的外部文件具有限制性权限。理想情况下，它应由 root:root 拥有，并且仅可由 root 用户或服务用户本身读取。
# 创建秘密文件
sudo touch /etc/secrets/my-app-credentials.env
# 用秘密信息填充文件
sudo sh -c 'echo "DB_PASS=S3cr3tP@ssw0rd" >> /etc/secrets/my-app-credentials.env'
# 设置限制性权限（root 只读）
sudo chmod 600 /etc/secrets/my-app-credentials.env
⚠️ 安全警告：文件权限
如果
EnvironmentFile引用的文件包含凭据，则权限必须设置为0600或更严格。如果文件可被其他用户读取，则秘密信息将在服务启动或手动检查期间暴露。
故障排除与验证
对单元文件或即时文件进行任何更改后，您必须重新加载 Systemd 管理器配置。
sudo systemctl daemon-reload
sudo systemctl restart my-app.service
要验证 Systemd 为运行中的服务成功加载了哪些环境变量，请使用 systemctl show 命令并专门查询 Environment 属性：
systemctl show my-app.service --property=Environment
示例输出（显示已加载变量）：
Environment=APP_PORT=8080 NODE_ENV=production DB_PASS=S3cr3tP@ssw0rd
如果服务启动失败，请使用 journalctl -xeu my-app.service 查看服务日志。与环境变量相关的常见故障原因包括：
EnvironmentFile中的文件路径不正确。- 文件缺失（且路径没有以
-为前缀）。 - 外部环境变量文件中变量语法不正确（例如，
=符号周围有空格）。
最佳实践总结
| 场景 | 使用指令 | 位置最佳实践 | 安全注意事项 |
|---|---|---|---|
| 静态、非敏感配置 | Environment |
直接单元文件或即时文件 | 安全风险低。 |
| 敏感凭据（秘密） | EnvironmentFile |
外部文件，通过即时文件（*.service.d/）引用 |
关键：环境变量文件必须具有 0600 权限。 |
| 模块化与覆盖 | EnvironmentFile |
即时单元文件 | 将配置与供应商默认值分离。 |
通过在专用即时单元中利用 EnvironmentFile 指令并确保严格的文件权限，管理员可以安全灵活地管理服务配置，遵守最小权限和关注点分离的原则。