使用ENV变量存储敏感配置是否合理？相关技术疑问求解

Hey there, this is such a relatable question—moving to 12-factor practices often brings up these practical hurdles, especially when you’re juggling multiple services with tons of secrets. Let’s unpack both the "why" and the "how to fix it" here.

First, let’s clarify why this approach is widely recommended, even if it feels cumbersome at first:

• Strict separation of config and code: Sensitive credentials don’t live in your codebase at all. That means you can safely commit your code to version control without worrying about accidentally leaking passwords, and you can switch between dev/staging/prod environments without modifying a single line of code.
• Reduced risk of accidental exposure: Config files are often shared, copied, or misconfigured (like being world-readable on a server). Environment variables are process-scoped by default, and you can control their visibility more tightly.
• Native support for modern tooling: CI/CD platforms, container orchestrators (K8s, Docker), and cloud providers all have built-in ways to manage and inject environment variables. This makes your app more portable across different deployment environments.
• No config file sprawl: Instead of maintaining separate prod.config, dev.config, test.config files (and keeping them in sync), you have a single way to manage configuration across all environments.

Now, onto your actual pain points—losing variables on reboot, needing to store them somewhere without breaking the 12-factor rule, and avoiding "secret amnesia":

Use Purpose-Built Secret Management Tools #

This is the gold standard for production and even local development:

• Local development: Libraries like dotenv (Node.js), python-dotenv (Python), or dotenv-rails (Ruby) let you store your secrets in a .env file (add this to .gitignore immediately!). When your app starts, it loads these variables into the environment automatically. You get the convenience of a file without risking accidental commits.
• Production/servers: Tools like HashiCorp Vault, AWS Secrets Manager, or GCP Secret Manager are designed to securely store secrets. They handle encryption, access control, and versioning, and you can inject secrets into your app’s environment at startup (via API calls or integration with your deployment tooling). Even if your machine reboots, you just pull the secrets again from the manager—no need to store them locally.

System-Level Persistence (For Small, Non-Critical Deployments) #

If you’re running a small app and don’t want to spin up a full secret manager, you can persist variables at the system level (but proceed with caution):

• Add variables to /etc/environment (global, applies to all users) or your app user’s ~/.bashrc/~/.profile file. Make sure to set strict permissions on these files (e.g., chmod 600 ~/.bashrc) so only the intended user can read them. Note that this is less secure than a dedicated secret manager, but it works for simple use cases.

Containerized Deployments #

If you’re using Docker or Kubernetes:

• Docker: Use docker run --env-file .env to load local secrets during development, or Docker Secrets for production (which mounts secrets as files instead of exposing them as environment variables, adding an extra layer of security).
• Kubernetes: Use Secrets or ConfigMaps to store sensitive data, then mount them into your pods as environment variables or files. Kubernetes handles secure storage and injection automatically.

CI/CD Platforms #

For tools like Travis CI or CircleCI, you don’t need to worry about storing secrets in files—these platforms have built-in secret management interfaces. You can input your variables directly in the platform’s settings, and they’ll be injected into the environment during builds/deploys automatically. No more hardcoding or committing secrets.

The core idea of using environment variables isn’t "never store secrets in files"—it’s "never store secrets in your codebase or public config files". By using dedicated tools to manage and inject secrets, you get the best of both worlds: the portability and separation of concerns that 12-factor promotes, plus a secure, reliable way to keep your secrets safe.

内容的提问来源于stack exchange，提问作者Flame_Phoenix