Instruction 05-environment-variables-secrets-and-configuration: Reading

Applications need values that differ between environments: ports, hostnames, feature switches, log levels, credentials, and cryptographic material. These values should not all be handled in the same way. Ordinary configuration may be safe to display during diagnostics, while a secret must remain confidential at rest, in transit, in logs, and during troubleshooting. Environment variables are useful because deployment systems can supply values without rewriting application code. They also support clean process-level overrides. However, an environment variable is not a secret vault. It can be inherited by child processes, copied into diagnostic bundles, exposed by careless process inspection, retained by automation systems, or printed during debugging. For this reason, use environment variables for non-sensitive overrides unless the deployment platform provides a carefully controlled secret-injection mechanism and its limitations are understood.

Configuration precedence must be explicit and predictable. This lesson uses built-in defaults, then a JSON configuration file, then selected environment-variable overrides. The most specific runtime source wins. Unrecognized or invalid values are rejected instead of silently accepted. Sensitive material follows a separate path: an environment variable contains only the pathname of a protected file, and the application reads the file after validating that it is inside the lab directory, is a regular file, has no group or other permission bits, and is not empty. The program reports only whether the value loaded; it never prints the value itself.

A configuration file should be treated as data rather than executable shell text. Loading an untrusted file with shell sourcing can execute commands, expand variables, or alter shell behavior. Structured formats such as JSON avoid that specific execution path, although they still require schema validation and safe permissions. Sensitive files should be readable only by the service identity and should not be committed to version control, copied into container images, embedded in command arguments, or included in support archives.

Rotation is another core requirement. Rewriting a file in place can briefly expose an empty or partial value to a concurrent reader. A safer pattern is to create a new file with restrictive permissions, fully write and flush it, and then atomically replace the active file on the same filesystem. Production systems may also need coordinated overlap, revocation, audit events, and service reload behavior. The lab uses a randomly generated, disposable training credential and never reveals its content. The important operational lesson is that secure configuration includes delivery, validation, observation, rotation, and cleanup rather than merely choosing where to store a string.