Secure Secret Handling and Environment Hygiene

Secrets — API keys, passwords, tokens — are the most sensitive data in any system. Mishandling them in Bash scripts is one of the most common and damaging security mistakes.

• Process listings: Arguments passed to commands appear in ps aux, /proc/<pid>/cmdline, and system audit logs — visible to all users on the host.
• Shell history: Commands typed interactively (and sometimes scripts) are recorded in ~/.bash_history.
• Log files: set -x traces, application logs, and CI/CD output can capture variable values.
• Environment leakage: Child processes inherit the full environment of their parent, including any exported secrets.

A hardened script treats secrets like radioactive material — minimise exposure time, limit surface area, and sanitise everything on the way out.

When you pass a secret as a command-line argument, every user on the system can read it immediately via ps. This is not theoretical — it is exploited routinely in shared hosting and container environments.

The snippet below demonstrates the problem and the fix side by side.

The safest interactive pattern is to read a secret at runtime using read -rs. The -s flag suppresses echo so the characters are never displayed, and -r prevents backslash interpretation.

Key points:

• The variable is never exported, so child processes cannot see it via /proc/<pid>/environ.
• After use, unset the variable immediately to shrink the exposure window.
• Avoid echo "$SECRET" — use printf '%s' to prevent a trailing newline from corrupting the value and to stay invisible in traces.

When a secret must persist on disk (e.g., a service account key), the file's permissions are your primary defence.

• Mode 0600 — readable and writable only by the owner. No group, no world access.
• Mode 0400 — read-only for the owner. Prefer this for keys you should never accidentally overwrite.
• Store secret files under a dedicated directory such as ~/.secrets/ or /run/secrets/ (the latter is a RAM-backed tmpfs on many Linux systems and survives only until reboot).
• Never place secret files inside a git-tracked directory without a rock-solid .gitignore.

curl supports a ~/.netrc file (or an arbitrary path via --netrc-file) that maps hostnames to credentials. This keeps authentication data completely out of the command line and script body.

The file format is simple:

machine api.example.com
  login admin
  password s3cr3t

Best practices:

• Always set chmod 0600 ~/.netrc — curl refuses the file if world-readable on some systems.
• Use --netrc-file /run/secrets/netrc to point at a tmpfs-backed or container-injected secret.
• Clean up temporary netrc files with a trap on EXIT.

Environment variables are a popular way to inject secrets into scripts (12-factor apps, CI/CD pipelines). However, they leak to every child process and appear in /proc/<pid>/environ for the lifetime of the process.

Defensive patterns:

• Import the secret into a local variable immediately and unset the env var so child processes cannot inherit it.
• Pass secrets to specific commands using env -i or inline assignment rather than the full inherited environment.
• Never export a secret variable — use assignment-only (no export) when possible.

set -x (xtrace) is invaluable for debugging but will print the value of every variable it expands — including secrets — to stderr. These traces often end up in CI logs or syslog.

Strategies to protect secrets while keeping tracing useful:

• Temporarily disable tracing around sensitive operations with { set +x; } 2>/dev/null.
• Re-enable afterwards with set -x.
• Redirect the xtrace output to a separate file descriptor that goes to a protected log file, not to the public log stream.

Even when you are careful, secrets sometimes find their way into log output — especially in verbose or legacy scripts. A logging wrapper function that redacts known patterns adds a safety net.

This pattern uses a regex-based replacement on all log output. It is a last-resort layer, not a substitute for the other hygiene practices already covered.

env -i starts a command with a completely empty environment, preventing any inherited variables — including accidental secrets — from reaching the child process. You then explicitly pass only what is needed.

This is especially useful when running untrusted scripts, build tools, or third-party utilities that might exfiltrate environment data.

tmpfs is a RAM-backed filesystem. Files written there are never flushed to disk, eliminating the risk of secrets surviving in swap, disk cache, or snapshots.

• On Linux, /dev/shm and /run/user/<uid> are typically tmpfs mounts.
• Always pair tmpfs usage with a trap EXIT to delete files when the script finishes.
• In containers (Docker, Kubernetes), secrets can be mounted as tmpfs volumes directly into /run/secrets.

The following script combines every technique from this lesson into a realistic deployment helper. Observe how each layer of defence reinforces the others:

• stdin read with -s — no terminal echo
• tmpfs secret file with trap cleanup
• env scrubbing — secret unset before any subprocess
• xtrace guard — trace paused around sensitive code
• log redaction — safety-net regex before writing to log

You have completed Secure Secret Handling and Environment Hygiene. Here is a concise reference of everything covered:

• Process listings: Never pass secrets as command-line arguments — they appear in ps aux and /proc/<pid>/cmdline. Use stdin piping or --netrc-file instead.
• stdin reads: Use read -rs to collect secrets interactively without terminal echo or shell history exposure.
• File permissions: Secret files must be chmod 0600 (or 0400). Use install -m 0600 for atomic creation.
• netrc files: Delegate credentials to a temp file pointed at by --netrc-file; clean up with trap EXIT.
• Environment hygiene: Immediately unset secret env vars after capturing them locally; never export them unnecessarily; use env -i for child isolation.
• xtrace guard: Wrap sensitive code in { set +x; } 2>/dev/null ... set -x to prevent debug traces from leaking values.
• Log redaction: Use a sed-based logger as a last-resort safety net.
• tmpfs: Store runtime secrets in /run/user/$UID or /dev/shm so they never touch disk; shred on exit.

Defence in depth is the key mindset: no single measure is sufficient, but layering them together makes secret leakage extremely difficult.