OpenBao makes secret loading an explicit startup step

What the public implementation shows

The gateway loads flat ASP.NET configuration keys from OpenBao KV v2 and requires only enough environment configuration to reach the vault.

Secret retrieval happens before production configuration validation and before the application begins serving requests. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleA service should know whether its secret source is available before it accepts financial traffic.

The decision behind the mechanism

A dedicated loader keeps database credentials, signing material, API keys, and identity settings out of images and committed files.

Lazy secret retrieval can let the service report healthy until the first financial request reaches a dependency with missing credentials. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Provide only vault connection bootstrap values via environment.
• Read one least-privilege runtime path.
• Never log loaded secret values.
• Run configuration validation after the merge.

How the control should be operated

Vault reachability, token-file permissions, KV mount, secret path, renewal model, and bootstrap ownership should be part of deployment readiness.

The service fails visibly at startup instead of discovering secret problems inside a payment flow. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.