Security Configuration Deployment Chain

Security Configuration Deployment Chain

A security setting only protects a service when the intended value reaches the running process. Trace configuration across the full deployment path instead of reviewing the application property or manifest in isolation.

Trace the value

Follow this chain for each security-sensitive setting:

1. Deployment parameter or template input.
2. Secret name and key, where the value is secret-backed.
3. Workload secretKeyRef or equivalent environment mapping.
4. Container environment variable.
5. Application property binding and active profile.
6. Effective value in a non-production runtime.

Check names and keys at each boundary. Review rendered manifests and the configuration loaded by the process. Repository YAML proves intended wiring, not that the deployed Secret exists, has the expected value, or reached a running workload.

Make missing configuration visible

An application default can hide a broken deployment mapping. Decide whether each security-sensitive value may have a default. If not, fail startup or deployment when it is missing rather than silently using a local or test value.

Waste Plus example

The reviewed COGNITO_CLIENT_ID path connects OpenShift templates and workload environment variables to Spring application configuration in both backend and legacy services. That establishes repository-level wiring only. It does not establish the value loaded by a deployed service.

Evidence sources

• common/openshift.init.yml
• backend/openshift.deploy.yml
• legacy/openshift.deploy.yml
• backend/src/main/resources/application.yml
• legacy/src/main/resources/application.yml
• final/security-coverage-test-plan-2026-10-05.md