Secrets, certificates, and configuration
Keep credentials and trust settings out of source control, examples and logs. Give deployed configuration an owner, validation rules and a recovery process.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Configuration and trust material lifecycle pattern; storage technology, cryptographic policy, deployment platform, product behaviour, and recovery controls are environment specific.
On this page
Overview#
Configuration is untrusted input with operational side effects. Parse it into a typed validated model, fail clearly on invalid or ambiguous values, and make the effective configuration observable without revealing secrets.
Configuration classes#
- static application behaviour and feature policy;
- deployment topology, addresses and protocol roles;
- tenant/site/resource mappings;
- credentials, private keys, tokens and trust anchors;
- runtime tuning such as timeouts, queue limits and retry budgets;
- high impact authorisation and actuation policy.
Don't treat all classes as interchangeable environment strings. Secret values require protected retrieval and redaction; trust anchors require controlled distribution; high impact policy requires authorisation and audit; tunables require bounds.
Loading pipeline#
- Load from named sources with documented precedence.
- Reject unknown critical keys and duplicate/conflicting definitions.
- Parse exact types, units and durations; avoid implicit coercion.
- Validate ranges, cross field invariants, URL schemes, paths, identities and secure modes.
- Resolve secret references without copying values into the configuration model or logs.
- Produce a redacted effective configuration fingerprint/version.
- Apply changes atomically or retain the last known good state.
Secret handling#
- Use references to an approved secret service/store, not values in Markdown or source.
- Grant access per workload and purpose, with short lifetime where possible.
- Avoid secrets in URLs, command arguments, process listings and error messages.
- Rotate with overlap/reconciliation and revoke the old material.
- Prevent crash reports, tracing and support bundles from capturing values.
Certificate configuration#
Configure the expected peer identity, trust anchors and TLS settings. Make certificate/hostname validation mandatory, expose expiry and issuer/serial for operations, and keep client key material separate from server trust.
Sources#
- NIST 800 57, NIST SP 800-57 Part 1 Rev. 5, key management guidance, accessed 25 August 2026.
- NIST SSDF, NIST SP 800-218 Version 1.1, secure development practices, accessed 25 August 2026.