Env config vs. secrets: What devs get wrong and why it’s risky

TL;DR

Configs are safe-to-share settings; secrets are sensitive credentials. Mixing them in the same .env or repo risks leaks, rotation debt, and breaches. Store configs in version control, but manage secrets with runtime injection, rotation, and strict access controls to keep deployments secure.

Early organizations are in the“move fast and break things” phase, where making it work is more important than good structure and secrets hygiene. Configurations and secrets also look very similar, as key-value pairs, so it is common to mix them.

However, configurations are not sensitive or subject to the same amount of scrutiny as secrets. If someone sees a LOG_LEVEL=debug, it’s not a big deal. If they get your S3 credentials, that's a breach, and an accidental disclosure can be disastrous for an organization(S3_BUCKET_PASSWORD = password).

By classifying secrets and configurations similarly, accidental exposure of secrets and credentials may occur. While it might be fine to push configurations to public GitHub files or to write configuration settings into logs, doing the same for secrets can lead to leaks or infiltrations. To avoid these possibilities, secrets must be separated from configurations and securely stored.

What counts as a config vs. what counts as a secret?

Secrets are values that, if exposed, could compromise data, infrastructure, or sensitive data. A value is considered configuration data if it does not lead to any exposure concerns. 

What goes wrong when you don’t separate them

If secrets are improperly stored in a configuration file, there is a potential for accidental exposure of the secret and the sensitive information it protects.If an .env file containing both secrets and configurations is exposed, the features using the secrets have been compromised.

Static secrets are notoriously hard to rotate. When a DBPASSWORD secretis defined in the .env, it can sit unnoticed for months. That means a regular rotation schedule has not been implemented, and the secrets are more likely to be compromised.

Conversely, if all the secrets and configurations are stored using a secrets management solution, a developer may be unable to update a harmless configuration change due to access restrictions.

While it might initially be“easier” to combine configurations and secrets into a single bucket, the risks of secrets exposure grow as more parameters are stored in the same service. To differentiate configs and secrets, create a mental model for your developer teams to understand how to properly separate secrets from configurations.

A mental model to differentiate secrets and configurations

To separate configurations from secrets, it is helpful for developers to have a set of rules that they can use to decide where to properly store the key-value pair: is it a configuration, or is it a secret?

Configurations control how the application behaves and interacts with systems. Any configuration should be safe to log, share, or commit. Some best practices around configuration management:

• Version control: Configurations should be versioned and can be reviewed and stored in Git.
• Shared: Configurations are safe to be shared across environments.
• Logging: Configurations can be logged, surfaced in dashboards, and appear in CI/CD outputs.
• Static: Configurations rarely need to be changed dynamically.
• Low risk: Exposure of configurations does not impact security.

• Ephemeral: Secrets should be short-lived and rotated frequently. Ideally, secrets can be created and updated during every deployment.
• Access control: Visibility of secrets should be tightly controlled withRole-Based Access Control(RBAC). Ideally, developers should not have access to see the secrets; only the runtime has access to them: the ultimate implementation of least privilege access.
• Audits: All secret usage should be logged and traceable to help resolve security risks.
• Exposure: Secrets that are exposed lead to unauthorized users and/or data loss.

Example approach to keeping secrets and configurations separate.

What are best practices for managing secrets and configurations?

So, what are the best practices for deploying environment configs vs. secrets? Since non-sensitive configuration data has a low risk if exposed, they can be placed in files that can be committed to Git(like Terraform or Helm charts). If stored in .env files, they can be more easily shared among team members.

For ease of use, configuration management should include version control to best verify that the latest values are being used. At deployment, all configurations should be validated to ensure that all the required values are present and are in the correct formats.

Git does not honor files placed into a .gitignore if they have already been previously committed. Ideally, secrets are injected at runtime, using CI/CD tools in conjunction with a secrets management tool like Doppler. Automatic injection helps to remove manual processes around secrets, reducing the likelihood of human error. Other automatic functions should include regularly rotating secrets to limit any exposure. All secret usage and rotation should be logged for auditing, allowing teams to be alerted to unusual access patterns.

Keep them apart to keep them safe

Development environments are awash with configurations and secrets. Since configurations and secrets have different jobs in the development process(anddifferent risk profiles), they should be treated differently from the start. Storing configurations is easy. They can be stored in public repositories or version control, appear in logs, and be shared freely across the team.

Secrets demand higher levels of protection. Leveraging a developer-first secrets management solution like Doppler provides your development team with environment isolation, encrypted storage, strict access controls, and regular rotation. By providing all of the controls needed for secrets management in developer-friendly tools, your team can be assured that their secrets are secured and safe from accidental exposure.