Harden OpenBao in-cluster traffic with TLS

Summary

The self-managed OpenBao chart currently disables listener TLS and its in-cluster clients use HTTP. Clients that authenticate with privileged tokens, including lifecycle hooks, therefore send those tokens without transport encryption inside the cluster network.

This needs a chart-wide migration rather than a one-client URL change because the listener, raft retry joins, health probes, migrations, auto-unseal, injector clients, and other OpenBao consumers share the current protocol contract.

Scope

• Provision or accept a server certificate and CA bundle for the OpenBao listener.
• Configure the listener and raft peer addresses for TLS.
• Migrate every in-cluster client to HTTPS with CA verification.
• Define backward-compatible upgrade behavior for existing plaintext installations.
• Consider namespace-scoped NetworkPolicies as defense in depth, without treating them as a substitute for encryption.

Acceptance criteria

• OpenBao serves authenticated API traffic over TLS in a self-managed installation.
• Lifecycle hooks and service clients verify the configured CA; insecure verification is not the default.
• No privileged OpenBao token is transmitted over plaintext TCP.
• A fresh installation and an upgrade from the current plaintext chart both pass the self-managed BDD and stateful upgrade tests.
• The chart documents certificate ownership, rotation, and recovery behavior.

Start by locating the self-managed OpenBao chart and its listener, raft retry join, probe, migration, auto-unseal, injector, lifecycle hook, and service-client configuration. Trace the existing self-managed BDD and stateful upgrade tests for fresh installations and plaintext upgrades; done means authenticated HTTPS traffic with CA verification, passing both test paths, and documented certificate ownership, rotation, and recovery.