Secrets Management for Rust Services in Production

Keep credentials out of images, repositories and logs. Compare environment variables, mounted files, systemd credentials and a secret manager, and plan for rotation.

3 min read

Summarize in AI

Quick Summary

Keep secrets out of the repository, the image and the logs. Deliver them at run time as mounted files or injected variables from systemd credentials, Kubernetes secrets or a secret manager, grant the least access needed, and design for rotation without a rebuild. Wrap values in a redacting type so they never print.

Key takeaways

A secret baked into an image layer is recoverable by anyone with the image, even if a later layer deletes it.
Environment variables are convenient and are visible to the process owner, to child processes and, in some setups, to anyone who can read container metadata.
Files mounted from a secrets store with mode 0400 are easier to scope and rotate than variables.
Rotate on a schedule and on any suspected exposure, and make the application tolerate two valid secrets during the swap.
Scan the repository for secrets in CI so a leaked key is caught before the push is merged.

Most credential leaks are not clever attacks. They are a .env committed in a hurry, a token in a Dockerfile ENV line, or a Debug print in a log aggregator. The defenses are boring and cheap if you decide them before the first deploy. This post compares four delivery methods and then lists the Rust-side habits that keep a secret from leaking after it arrives. It is the secrets step of shipping Rust to production, following configuration from the environment.

Rust 1.90.

Where secrets must not be

Place	Why not
Source repository	history is permanent and widely cloned
`Dockerfile` `ENV` or `ARG`	stored in image layers and visible in `docker history`
Compile-time `env!` or `include_str!`	baked into the binary, readable with `strings`
Command line arguments	visible in `ps` to other users
Logs and error messages	copied into aggregators with long retention

Four ways to deliver them

Environment from the orchestrator. Kubernetes Secret as env, a systemd EnvironmentFile owned by root, Fly or Heroku config. Simple, widely supported. Visible in /proc/PID/environ to the same user and root.
Mounted files. Docker secrets appear at /run/secrets/name; Kubernetes can mount a Secret as a file; systemd's LoadCredential= provides $CREDENTIALS_DIRECTORY/name. The application reads the file at startup. Permissions scope who can read it.
Secret manager API. AWS Secrets Manager, GCP Secret Manager or Vault, fetched at startup with the instance's identity. Central audit and rotation, and an extra dependency and failure mode at boot.
Encrypted in the repository. SOPS or age encrypted files committed, decrypted at deploy. Works for small teams without a manager; the decryption key is the secret that remains.

Pick the simplest one your platform already offers. Do not build your own.

Reading a file secret in Rust

rust

use std::{fs, io};

fn read_secret(name: &str) -> io::Result<String> {
    let dir = std::env::var("CREDENTIALS_DIRECTORY").unwrap_or_else(|_| "/run/secrets".into());
    Ok(fs::read_to_string(format!("{dir}/{name}"))?.trim().to_string())
}

Trim the trailing newline that editors add. Treat a missing file as a startup error, as in the validation in the configuration post.

Keep it from leaking after it arrives

Wrap values in a type with a redacting Debug, or use the secrecy crate, which also zeroes memory on drop. See handling secrets with zeroize and secrecy.
Do not log request headers wholesale; Authorization and Cookie carry credentials.
Do not include a secret in an error message, including connection strings with passwords.
Do not pass secrets as command line arguments to child processes.

Rotation

A secret that cannot be rotated without downtime will not be rotated. Support two active values at once where the protocol allows it: accept tokens signed with the old and new keys during a window, or re-read the file on SIGHUP. For database passwords, create the new user, switch, then delete the old one. Put rotation on a calendar and test the procedure; an untested rotation fails during an incident.

Catching mistakes early

Run a scanner such as gitleaks or trufflehog in CI and as a pre-commit hook. Set .gitignore for key files (git ignore for Rust projects). A leaked cloud key is abused within minutes by automated scanners, so assume exposure and rotate.

Limits

No delivery method protects against an attacker who has code execution as the service user; they can read what the service reads. The defenses reduce the chance of accidental disclosure and limit the blast radius. The OWASP Secrets Management Cheat Sheet is the primary reference.

Also inSecurity

Taggedsecrets