bao-kms-provider runs on every control-plane node and lets kube-apiserver
encrypt Secrets and other resources with an OpenBao Transit key before they
reach etcd. These steps set it up for one cluster, in order.
The path
| Step | Page | Outcome |
|---|---|---|
| 1 | Before you begin | You know whether the provider fits, and you pick a deployment model and a credential source. |
| 2 | Download the release | You have one verified release artifact. |
| 3 | Generate installation files | One values file produces matching configs, policy, OpenBao setup, and an installation record. |
| 4 | Prepare OpenBao | An administrator reviews and runs the generated setup once. |
| 5 | Run with systemd or Run as a static pod | The provider runs on every control-plane node and passes its checks. |
| 6 | Enable encryption | Every API server reads KMS before any writes it, and a probe Secret reads through each one. |
| 7 | Verify encryption | etcd stores the probe as ciphertext and every provider reports the same key. |
What you need
- A Kubernetes cluster whose control-plane nodes you can administer. Select an exact version from your provider release’s tested matrix .
- An OpenBao cluster reachable over HTTPS from every control-plane node, and an administrator token for it. Select an OpenBao version from the same tested matrix.
- A JWT issuer for the provider’s host credential that keeps working when the protected API server is down.
- On your workstation: the
baoCLI,curl, andcosign. An authenticated GitHub CLI (gh) is optional, for build provenance checks.
To try the provider without a cluster or OpenBao of your own, contributors maintain a local lab that builds the provider from source and wires it into a Kind cluster with one command. See Contribute: Local lab .
After Get started, continue with Operate for rotation, upgrades, and recovery, and Configure for auth and policy variants and monitoring.