Configuration and Secrets: Selecting Behavior Without Exposing Authority

The same application code may run in development, testing, and production while connecting to different databases, using different feature settings, and receiving different credentials.

These values should not all be compiled into source code.

Code defines behavior, configuration selects behavior for an environment, and secrets grant sensitive authority.

Configuration and secrets may travel through similar delivery systems, but they deserve different handling.

A concrete example: a database connection

An application needs:

Database host: db.production.internal
Database name: orders
Username: checkout-service
Password: ...

The host and database name are configuration.

The password is a secret because possession grants access.

Committing all values into source code causes:

• Environment coupling
• Secret exposure
• Difficult rotation
• Accidental production access during testing

The application should receive them at deployment through controlled mechanisms.

What belongs in configuration

Configuration may include:

• Service addresses
• Port numbers
• Feature flags
• Timeout values
• Log level
• Region
• Queue names
• Capacity limits
• Public identifiers

Not every value should be configurable.

If an option will never differ and changing it would violate design, keeping it in code can be clearer.

Excessive configuration creates a second programming language with poorly tested combinations.

Make variation intentional.

Configuration is part of system state

A running system's behavior depends on:

• Code version
• Configuration values
• Feature flags
• Infrastructure
• Data

Two instances running the same binary can behave differently because configuration differs.

Therefore configuration should be:

• Versioned where appropriate
• Reviewable
• Validated
• Auditable
• Reproducible

Incident investigation needs to know which configuration was active at the time, not only which code commit was deployed.

Common delivery mechanisms

Configuration can arrive through:

• Environment variables
• Command-line arguments
• Configuration files
• Platform configuration APIs
• Service discovery
• Remote configuration systems

Each has tradeoffs.

Environment variables are broadly supported but can be exposed through process inspection or diagnostics.

Files support structured data but need permissions and reload behavior.

Remote systems enable dynamic change but introduce availability, authorization, and consistency concerns.

Choose based on operational needs and threat model.

Validate at startup

Fail early when required configuration is missing or invalid.

Instead of discovering after traffic arrives that PAYMENT_TIMEOUT contains fast, validate:

• Presence
• Type
• Range
• Allowed values
• Relationships among fields

Example:

PORT must be an integer from 1 to 65535.
SESSION_TTL must be shorter than TOKEN_MAX_AGE.

Error messages should identify the field without printing secret values.

A typed configuration object prevents string parsing from spreading through application code.

Defaults need care

Defaults are useful for safe common behavior.

Dangerous defaults include:

• Authentication disabled
• Public network binding
• Infinite retry
• Debug logging with sensitive data
• No TLS verification

Production systems should fail closed when a security-critical value is absent.

Development convenience should not silently become production behavior.

Separate explicit local configuration rather than use an unsafe universal default.

Secrets are credentials and keys

Secrets include:

• Passwords
• API keys
• Private cryptographic keys
• OAuth client secrets
• Session-signing keys
• Database credentials
• Recovery tokens

Some values are sensitive but not secrets, such as personal records.

The distinction matters:

• Secrets grant authority.
• Sensitive data needs confidentiality and privacy protection.

Both require access control, but rotation applies differently.

Do not commit secrets

Source repositories are widely copied:

• Developer machines
• CI systems
• Backups
• Forks
• Code-review tools

Deleting a secret from the latest file does not remove it from history.

If a secret is committed:

1. Revoke or rotate it immediately.
2. Assess where it was used.
3. Review logs for misuse.
4. Remove it from current code.
5. Clean history only when useful, without treating cleanup as revocation.

Secret scanning can detect common patterns before and after commits.

Secret managers

A secret manager stores encrypted secrets and controls retrieval through identity and policy.

Capabilities may include:

• Access audit
• Versioning
• Rotation
• Expiration
• Dynamic credentials
• Encryption using managed keys
• Fine-grained policy

Applications authenticate to the secret manager using a workload identity rather than another long-lived secret where possible.

The secret manager becomes critical infrastructure and needs availability, backup, and emergency-access planning.

Prefer short-lived credentials

Long-lived credentials remain useful to an attacker until revoked.

Short-lived credentials:

• Expire automatically
• Reduce exposure after theft
• Support scoped access
• Improve attribution

Examples include temporary cloud roles, database credentials generated per workload, and time-limited access tokens.

The issuing identity system must be secure, and applications need renewal behavior.

Expiration without reliable refresh creates availability failures.

Rotation

Rotation replaces a credential or key.

A safe process often supports overlap:

1. Create new credential.
2. Allow old and new during transition.
3. Deploy consumers using new credential.
4. Verify use.
5. Revoke old credential.

Immediate replacement can break clients that have not refreshed.

Some signing-key systems publish multiple public keys so old tokens remain verifiable during a controlled lifetime.

Rotation should be practiced before an emergency.

Secrets in memory and logs

An application must use secrets somewhere, often in process memory.

Reduce exposure:

• Do not log configuration objects wholesale.
• Redact headers and connection strings.
• Avoid secrets in URLs or command-line arguments.
• Limit crash dump access.
• Clear temporary files.
• Restrict debugging interfaces.

Masking only fields named password misses token, authorization, and provider-specific values.

Log schemas should classify sensitive fields explicitly.

Encryption is not enough by itself

Encrypting a secret file protects stored bytes, but the application needs a decryption key.

Ask:

• Who can decrypt?
• Where is the key?
• Can access be audited?
• Can one compromised account retrieve every secret?
• How is emergency recovery handled?

Storing the encrypted file and its decryption password together with identical permissions adds little protection.

Key and identity separation creates the meaningful boundary.

Configuration changes need deployment discipline

A configuration change can cause as much impact as code:

• Set timeout too low
• Route traffic to wrong service
• Disable a security check
• Increase concurrency beyond database capacity

Use:

• Review
• Validation
• Staged rollout
• Monitoring
• Rollback
• Change history

Dynamic configuration should define propagation timing and behavior when instances temporarily disagree.

Local development

Developers need safe ways to run software without production credentials.

Options include:

• Local emulators
• Development-only accounts
• Seeded test data
• Personal short-lived credentials
• .env files excluded from version control

Do not copy production databases or shared administrator secrets merely for convenience.

Development environments are frequent attack paths because they contain powerful tools and relaxed controls.

Keep access scoped and data appropriately sanitized.

Ownership and inventory

For each secret, record:

• Owner
• Purpose
• Systems using it
• Scope
• Creation time
• Expiration
• Rotation method
• Emergency revocation

Unknown dependencies make rotation frightening, which leads to credentials living for years.

An inventory turns rotation and incident response into planned work.

Configuration also needs ownership so obsolete flags and values do not accumulate indefinitely.

Knowledge check

1. How do code, configuration, and secrets differ?
2. Why should configuration be part of incident and deployment history?
3. What should happen after a secret is committed to a repository?
4. Why are short-lived credentials valuable?
5. What makes secret encryption meaningful rather than merely cosmetic?

The one idea to remember

Keep deploy-time choices and access-granting secrets outside source code. Validate configuration, deliver secrets through identity-controlled systems, minimize their lifetime and scope, and make changes, rotation, and recovery routine.