Why teams replace manual unsealing with OpenBao auto-unseal
Teams replace manual unsealing because a restarted or failed-over OpenBao node stays sealed until operators supply Shamir key shares. Recovery therefore waits on people being reachable, and protection of the root key depends on the few individuals who hold shares and the procedure they follow. Auto-unseal changes that model. The node hands protection of its root key to an external seal, so on startup it asks that seal to unwrap the key without anyone entering shares. The decision in front of you is which seal your organization can operate, monitor and recover under its own controls. The rest of this topic works through that choice and the work it creates.
OpenBao can use three families of external seal: PKCS#11 hardware security modules, KMIP key managers, and cloud key management services. Each moves custody to a different place. An HSM you own keeps key material inside your data center or hardware boundary, which adds procurement, firmware and failover planning. A cloud KMS keeps keys in a provider account governed by your IAM policy, so access reviews and key policies become part of the unseal design. A KMIP service depends on whichever key manager you already run. Seal support changes over time, so confirm in the OpenBao seal documentation for the exact version you plan to run which seal types are supported, their maturity labels and their limits. Also confirm how the external KMS plugin mechanism added in 2.6.0 works: which plugins ship, who maintains them and how they upgrade alongside the server.
Auto-unseal does not remove recovery material. With an external seal, recovery keys take the place of unseal keys for some operations, such as generating a new root token. Confirm the exact operations that require them in the OpenBao docs for your version. Decide who holds recovery key shares, how many shares are required, where each share is stored and how holders are reached during an incident. Store shares under separate custody so that no single administrator can both reach the seal and hold the recovery material. Write a break-glass procedure that names the steps, approvals and audit evidence. Test it on a non-production cluster before you rely on it, because a seal that is unreachable during an outage will stop nodes from unsealing even when everything else is healthy.
Before you choose a seal, inventory the clusters you run, the people who hold unseal material today and the failure domain of each candidate seal. A seal in the same rack or region as the OpenBao nodes fails with them, so placement is an architecture decision that should be made early. Ask any implementation partner to scope the seal integration, the recovery procedure, the test plan and the handover in writing. Cost comes from hardware or provider key charges, integration and testing effort, and ongoing operation of the seal and its monitoring. Ask which costs are one-time and which recur, and what changes if you add a second cluster or a second region.
What you need before changing the seal
Changing the seal alters how every node gets its unseal material, so preparation covers the software version, the key store, the network, the certificates and the existing key material. Work through each card before you schedule a change window, and confirm each item against your own environment. Each seal has its own requirements, so confirm them with the vendor or the OpenBao documentation before procurement.
Target OpenBao version
Confirm which OpenBao release supports the seal you plan to use. External KMS plugins were added in 2.6.0, so a cluster on an earlier line needs an upgrade before the change. Plan the path from your current version to the target, check the release notes at each step, and rehearse the full sequence on a non-production cluster that matches your storage backend and node count. Record the exact version on every node so you can confirm consistency afterward.
HSM or KMS account and key
Confirm the account, key and access policy that OpenBao will use to protect its root key. Record the key identifier, key type, rotation schedule, and which identities can disable, rotate or delete it. A disabled or deleted key blocks unsealing on every node, so check deletion protection and whether the product allows you to back up key material. Confirm each seal's key requirements with the vendor before procurement.
Network paths from every node
Every node, including standbys, must reach the key store directly, because any node can become active after a failover and then needs to unseal. Map firewall rules, proxies, DNS names and egress routes from each host and from each data center or availability zone. Test from the actual service account and host that OpenBao runs under, through the same path the service uses. Confirm the ports and protocols the seal requires in its documentation.
TLS and certificate material
Where the key store is reached through KMIP or an HSM client library, the connection may require client certificates and a trusted CA chain. Collect the certificate profile the vendor requires, including key usage, extended key usage and subject alternative names, and record issuance and expiry dates. An expired client certificate can stop a node from unsealing after a restart, so schedule renewal and test a restart after installing each new certificate.
Current unseal key inventory
List every unseal key share and recovery key in use, who holds each one, and where it is stored. Moving to an auto-unseal seal changes the role of these keys, so confirm in the OpenBao documentation which material stays as recovery keys and which can be retired. Store the inventory in a controlled location, and verify that a quorum of current shares still works before the change window opens.
Choosing between PKCS#11 HSM, KMIP and cloud KMS seals
A PKCS#11 seal calls a hardware security module through the PKCS#11 interface, so the wrapping key stays inside the module and OpenBao receives only the results of each operation. This suits organizations that already run HSMs for certificate authorities, payments or document signing and want OpenBao key custody under the same governance.
- Key store requirement: an HSM or HSM-backed service with a PKCS#11 library that matches the OpenBao build you deploy, plus the key mechanisms the seal needs. Confirm both for your exact version.
- Operator: usually the security or infrastructure team that owns the HSM, including its partitions, firmware, backups and access policy.
- Startup behavior: if the library, network path or HSM partition is unavailable, the node cannot unseal and stays sealed until the call succeeds, so restarts depend on HSM availability.
- Audit evidence: HSM logs, key ceremony records and partition access reviews support key custody claims, and they must be correlated with OpenBao audit logs to show which identity used which secret.
Before committing, confirm PKCS#11 support, the library path and plugin status for your OpenBao version, then test a full cluster restart against the HSM.
KMIP is a standard protocol that lets OpenBao ask a key management server to wrap and unwrap its root key. It is a common choice when an organization already runs a KMIP-capable key manager for databases, storage arrays or tape encryption and wants one key service across several platforms.
- Key store requirement: a KMIP server that supports the operations the seal uses, and a client certificate chain that every OpenBao node can present. KMIP profile conformance varies by product, so verify the exact operations.
- Operator: the key management team that runs the KMIP server, its certificate authority and the lifecycle of the seal key object.
- Startup behavior: a failed KMIP call leaves the node sealed. Expired certificates on either side are a frequent cause of failed unseals, so track them alongside the seal key.
- Audit evidence: the KMIP server logs key operations and client identity, which helps auditors, provided each client certificate maps to one node or service identity.
Before committing, confirm KMIP operation support, certificate handling and plugin status for your OpenBao version, and rehearse certificate rotation before go-live.
A cloud KMS seal sends wrap and unwrap requests to a managed key service at a cloud provider. The provider runs the key hardware, so your team manages IAM policy, networking and key lifecycle rather than HSM partitions or firmware. This suits organizations that already operate a cloud account with governed key policies.
- Key store requirement: a key in the provider's KMS, an identity for the OpenBao nodes limited to encrypt and decrypt on that key, and network routes from every node to the provider endpoint.
- Operator: the cloud platform team manages the account, keys and policies, while the provider operates the underlying infrastructure under its shared responsibility model.
- Startup behavior: nodes depend on provider API availability, identity federation and outbound network access. A regional disruption or revoked permission keeps nodes sealed, so plan fallbacks where your policy allows.
- Audit evidence: provider audit logs record key use with identity and time. Confirm where those logs are stored, who can read them, and whether the provider's data residency terms match your regulatory scope.
Before committing, confirm the provider integration, credential method and plugin status for your OpenBao version, and check key location options against your residency requirements.
Configuring OpenBao auto-unseal step by step
This sequence moves an OpenBao cluster from manual Shamir unsealing to automatic unsealing through an HSM or cloud KMS seal, with recovery keys held under your control. Each step closes with a check that the cluster behaves as expected before the next step begins. Confirm every command, flag and configuration key against the documentation for the OpenBao version you run.
Prepare the key object and access policy
Your key administrator creates the wrapping key in the HSM or cloud KMS and grants only the encrypt and decrypt operations to a dedicated identity used by OpenBao nodes. The platform team stores that identity's credentials in the approved secret store and confirms which nodes can reach the key service over the network. Check: a test encrypt and decrypt round trip succeeds from each OpenBao node's identity, and the same identity is refused for any other key operation. Confirm the exact permission names and HSM partition setup with your HSM or KMS vendor's documentation.
Build a non-production test cluster
Your platform team deploys a cluster that matches production in node count, storage backend, network layout and OpenBao version, but uses a separate key and separate data. Engineers initialize it with Shamir keys in the usual way and take a storage snapshot before any change. Check: all nodes are initialized and unsealed, a sample secret can be written and read, and the snapshot restores into a scratch environment. Only proceed once the test cluster behaves like the production design.
Add the seal stanza to server configuration
Engineers add the seal block for the chosen HSM (PKCS#11 or KMIP) or cloud KMS to the server configuration on each test node, using the same settings on every node. If the cluster was bootstrapped on Vault, they also remove the disable_mlock setting, as the migration guide requires for OpenBao. Check: each node validates its configuration and restarts without errors, and its status output reports the configured seal type. Keep the Shamir keys available, because they are still needed for the migration in the next step.
Migrate the cluster from Shamir to the new seal
The engineer lead follows the seal migration procedure in the OpenBao documentation for the version in use, with the Shamir keys supplied by the authorized key holders. The procedure converts the cluster to the new seal and produces recovery keys, which the custodians record and store in separate locations as defined in the key management plan. Check: seal status shows the new seal type on every node, the recovery keys are recorded in the custody log, and no key material is held in plain text on engineer workstations.
Restart the cluster in a controlled order
The operations team takes a fresh snapshot, then restarts the standby nodes one at a time, followed by the active node, and waits for each node to rejoin before moving on. No operator enters an unseal key during the restart. Check: every node returns to unsealed status without manual input, and a standby node unseals on its own after its restart completes. Record the order, timings and any warnings in the change record.
Rehearse failover and recovery key use
Operators stop the active node in the test cluster, observe leadership moving to a standby, and confirm the restarted node unseals automatically when it returns. They then run a recovery key exercise with the custodians, following the documented recovery procedure, to confirm the keys work and the custody process is clear. Check: leadership transfers as expected, the failed node unseals without intervention, and the recovery exercise produces a signed record. Repeat the same sequence in production only after an approved change record, using the lessons from this run.
How recovery keys work after a seal migration
After you move from Shamir unsealing to an auto-unseal seal, the cluster no longer needs operators to supply unseal keys at each start. The material created at initialization changes role. Recovery keys take over the operations that still need human quorum, such as generating a root token or rekeying the recovery key shares themselves. Auto-unseal removes a routine daily step, but it does not remove the need to protect the material that can rebuild administrative access. Your team still needs a documented custody process that names who holds each share, where each share is stored, how a holder is replaced, and how you prove which shares are current.
The OpenBao migration guide notes that Vault clusters bootstrapped before Vault 1.3 may need a rekey before you move to OpenBao. Check how your existing cluster was initialized before you schedule anything. If it predates Vault 1.3, treat the rekey as its own change window with the same custody steps, because new shares must be distributed to holders and the old shares retired. Confirm in the OpenBao docs what the rekey procedure is for your version and whether it applies to recovery keys under your seal configuration. Do not assume the step is irrelevant only because the cluster runs well today.
The migration guide also says OpenBao stopped using mlock in 2.0.0, so disable_mlock must be removed from configuration. Review the configuration of every node, including files rendered by configuration management, Helm values and container images, because a leftover line is easy to miss on one node. While you are in the file, check the seal stanza itself. The HSM or cloud KMS parameters should reference a key you can name and audit, and any credentials should come from the platform identity or a protected file with restricted access, not from values pasted into a shared template.
Before cutover, run the recovery procedure against a non-production copy of the cluster. Generate a root token using recovery shares from your custody records, confirm the operation appears in the audit log, and then revoke the token. This test shows whether the people and documents you named can actually perform the task under pressure. Confirm recovery key behavior for your version in the OpenBao docs and with the team that operates your seal, and do not rely on Vault behavior as a substitute. The migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise, so Enterprise users should verify each step in their own environment and schedule a repeat drill after every major change.
Which seal settings map to which key custody decisions
This table maps each seal decision in an OpenBao auto-unseal design to the team that owns it, the system where its record lives and the evidence an assessor will expect to see. Use it as a checklist before go-live and again after any change to the seal. The main takeaway is that the HSM or cloud KMS key policy, not the OpenBao configuration file alone, decides who can unseal the cluster.
| Seal decision | Owner | System of record | Evidence to keep |
|---|---|---|---|
| Seal type | Security architecture, with platform engineering | Approved design record and the OpenBao server seal configuration | Signed design decision naming the PKCS#11, KMIP or cloud KMS seal and the reason it was chosen |
| Key or object identifier | Key custodian for the HSM partition or cloud KMS account | HSM or KMS inventory listing key label, identifier and region | Key metadata export showing identifier, purpose and deletion or scheduled-destruction controls |
| Access identity for the seal | Cloud or HSM identity team | IAM policy or HSM role bindings for the OpenBao service identity | Policy export showing only the OpenBao service identity can use the key, with key administration held separately |
| Recovery key holders | Key custodians, approved by security governance | Custodian register listing holders, quorum rules and review dates | Signed custodian acknowledgements and the roster of recovery holders with their last review date |
| Storage of recovery material | Security operations, with records management | Sealed custody location outside the cluster it protects, logged in the custody register | Custody log showing location, access events and any retrieval or recovery test |
| Audit logging of seal operations | Security monitoring team | OpenBao audit device and HSM or KMS audit trail, forwarded to the log platform | Sample seal, unseal and key use events confirmed against your OpenBao version's audit output, plus retention and alert settings |
Hardening the OpenBao auto-unseal key path
Auto-unseal moves the trust that Shamir key shares used to carry onto an HSM or cloud KMS key. The controls below decide who can use that key, which identities can reach it, and how recovery material is held, so a compromised node or operator does not automatically yield the ability to unseal the cluster. Confirm the exact control names and options for your chosen key store with its vendor, because the mechanics differ across PKCS#11 HSMs, KMIP appliances and cloud KMS services.
Key access policy on the HSM or KMS
Restrict use of the unseal key to the OpenBao node identities that must call it for encrypt and decrypt operations, and nothing else. Separate the permission to use the key from the permission to manage or delete it, and confirm whether your key store logs both types of call. Review the key policy or HSM partition permissions as part of the build, not after go-live.
Least-privilege identities for each node
Give every OpenBao node its own identity, such as a dedicated service principal, client certificate or HSM user, rather than one shared credential. Each identity should be limited to the unseal key and the minimum operations needed for auto-unseal. Confirm how your platform issues, rotates and revokes these identities, since node replacement depends on it.
Network restrictions to the key store
Limit which hosts can reach the HSM or KMS endpoint, for example through private endpoints, firewall allow lists or dedicated HSM network segments. Only OpenBao nodes should open these connections, and the path should not depend on general internet egress. Verify the restriction from both an allowed node and a blocked host during testing.
Separation of duties for operators
Assign cluster operators, who run and upgrade OpenBao, to different people than key administrators, who create, rotate and manage the unseal key. Neither role should be able to complete the other's sensitive actions alone. Document the approval steps for key rotation and for changes to key policies, and check that audit logs record who performed each action.
Split custody of recovery keys
Recovery keys are the fallback if the external key store is unavailable or the seal configuration fails, so they need their own protection. Split recovery material between several trusted custodians so that no single person can reconstitute it, and store each part in a separate controlled location. Agree the procedure for recovery ceremonies in advance and rehearse it in a non-production environment.
Why OpenBao auto-unseal fails after a restart
This table lists the failures that most often stop an OpenBao node from unsealing automatically after a restart. Each row gives the likely cause, how to confirm it from logs or status output, and the fix. Work through the rows in order, because a network or credential problem hides the configuration problems behind it.
| Failure | Likely cause | How to confirm | Fix |
|---|---|---|---|
| Node cannot reach the HSM or KMS endpoint | Firewall, security group, DNS or proxy change blocks the node from the HSM, KMIP server or cloud KMS endpoint after the restart | Check the server log for connection timeouts or refused connections on the seal startup. Test reachability from the same host, using the same DNS and network path the service uses | Restore the network rule or DNS record, then restart the node. Confirm the endpoint resolves and answers from the host itself, not only from your workstation |
| Client certificate or credential has expired | The HSM client certificate, KMIP certificate, cloud workload identity or access key used by the seal has passed its validity period or was rotated | Look for authentication or TLS errors in the log. Check the expiry date of the certificate or credential file on the node and compare it with the failure time | Issue or rotate the credential, deploy it to every node, and update the seal configuration to point at the new file or identity. Ask your security team who owns renewal |
| Key identifier or partition is wrong | The key label, key ID, KMS key ARN or resource name, or HSM partition in configuration does not match the key that wrapped the stored data, often after a key was recreated or copied to another partition | Compare the configured identifier with the key reference recorded at initialization. Check the log for errors that name the key or partition and for decryption failures | Correct the identifier in configuration on every node. If the key was replaced, restore the original key from backup. Do not reinitialize the cluster to work around a missing key |
| Seal type in configuration does not match the stored seal | The node is configured for a different seal type than the one recorded in storage, for example Shamir after a move to KMS or the reverse, or a changed seal stanza during a migration | Check the status output for the seal type and compare it with the seal stanza in the configuration file. Read the startup log for a seal mismatch message | Restore the seal stanza that matches the stored seal. Plan any seal type change as a documented migration with its own rekey or seal migration step, rather than an edit during a restart |
| Old disable_mlock setting remains in configuration | A configuration carried over from a Vault deployment still sets disable_mlock, which OpenBao no longer uses since version 2.0.0 | Search the configuration files and the systemd or container environment for disable_mlock. Read the startup log for warnings about the removed option | Remove the setting from every node configuration, then restart. Confirm the node starts cleanly with the same seal settings. Record the change in the change ticket |
| Recovery keys are missing during a maintenance task | Recovery keys or recovery shares were not stored in a controlled location, or the custodians needed to hand them over are unavailable when a seal fault forces a manual step | Check the runbook for the list of recovery key holders and the storage location. Ask whether the keys can be retrieved and whether the threshold can be met with the people available | Keep recovery key custody documented, split across named custodians, and tested in a drill. Store the recovery material in a location separate from the cluster itself, and rehearse the recovery path before each maintenance window |
Testing seal failover and recovery before go-live
The first goal of this test plan is to show what your OpenBao cluster does when its seal provider is unavailable, before a production incident forces the question. Start by recording the baseline in a staging cluster that mirrors production: the OpenBao version, the seal stanza for your chosen method (PKCS#11 slot and key label, KMIP endpoint, or cloud KMS key identifier), the storage backend, and which node currently holds the active lock. Confirm the expected seal and unseal behavior in the OpenBao documentation for that exact version, since seal handling and recovery key rules are version-specific and should be checked against the release you deploy rather than older Vault material.
Begin with controlled restarts. Restart each standby node one at a time, then the active node, with the seal provider reachable. For each restart, confirm that the node unseals automatically, rejoins the HA group, and that the active lock moves only as expected. Watch the health endpoint for sealed status, check that traffic through your load balancer continues, and review the audit device output for unexpected errors. Repeat the restarts while the seal provider is blocked to see which nodes stay sealed and how the cluster behaves with fewer healthy members than your quorum requires.
Next, simulate loss of the key store endpoint. Block each node's path to the HSM, KMIP service or cloud KMS using a firewall rule, a security group change, or by stopping the KMIP proxy in staging. Observe whether running nodes remain unsealed, what happens when a node restarts during the outage, and how quickly each node recovers once the path returns. Also test credential failures separately, such as an expired HSM PIN or a revoked cloud IAM role, because these fail differently from network loss. Record what alerts fire and whether your monitoring reports the sealed state clearly enough for operators to act.
Then rehearse node replacement and recovery key use. Remove one node, provision a replacement with the same seal configuration, certificate identity and cloud or HSM access, and confirm it joins and auto-unseals without manual steps. Next, rehearse the scenario where the seal provider is permanently lost. Have the named recovery key custodians perform the documented steps, confirm which operations accept recovery keys in your version, and time the handoffs. Keep custodians, quorum requirements and storage locations of the keys in the rehearsal record, and check that nothing in the process depends on a single person.
Before any test begins, write a rollback procedure: how to revert the seal stanza to the previous method, how to re-join a node that fails to recover, and the point at which the team stops testing and escalates. Each test should record the date, operator, version, expected result, observed result and change ticket. Store these records with the change record so operations and audit teams can review them. The evidence shows how your team operated the controls, but independent auditors decide what it demonstrates for any compliance assessment.
Questions buyers ask before hiring help with OpenBao auto-unseal
What drives the cost of OpenBao auto-unseal work?
The main cost drivers are the seal type, the number of clusters, who owns the key store, whether you are migrating from Shamir unsealing, and how deep the testing goes. Each seal type has its own configuration path and failure modes, so a PKCS#11 HSM build differs from a cloud KMS seal or a KMIP integration. Every cluster that moves to auto-unseal repeats configuration, validation and recovery testing, so cluster count multiplies effort. Key store ownership adds coordination work, since access requests, network paths and change approvals may sit with a separate HSM or KMS team. Migration from Shamir adds a planning and cutover step on live clusters. A quote follows a written scope that names these items. Ask for the quote to separate one-time build work from recurring support.
How long does an OpenBao auto-unseal project take?
No duration applies until the scope is written, because the scope sets the schedule. The largest schedule factors are how quickly your key store team can grant access, how many change windows you can use for each cluster, and whether a staging environment mirrors the production seal configuration. Teams that already operate an HSM or KMS with documented access paths usually move faster than teams that must first provision one. Testing depth also sets the timeline, since failover, restart and recovery drills take time to run and repeat. Ask any partner to show the phases, the approval gates each phase depends on, and which items sit on your side of the plan before you agree on dates.
What does our team need to provide for auto-unseal help?
Plan to provide four things: access to the key store, change windows for each cluster, named key custodians, and a staging environment. Key store access means a service identity or key with the permissions the seal needs, plus network paths from each OpenBao node. Change windows need agreed dates because restarts and seal changes affect availability. Named key custodians are the people who hold recovery key material and can authorize recovery actions, so they should be named before work starts. A staging environment that matches your production seal type lets the team test unseal, failover and recovery without risk to live secrets. Confirm each item in writing so the schedule reflects actual availability.
Can an internal team set up OpenBao auto-unseal alone?
Yes, an internal team with OpenBao operations skills and access to the key store can do the work alone, provided it has the time and the approvals. The hard parts are less the configuration syntax and more the recovery design: deciding who holds recovery keys, testing failover, and proving that a cluster can restart without an operator present. Teams that have not run seal changes before often underestimate the staging and rehearsal effort. Some organizations bring in outside help for the design and test plan, then run the rollout themselves. To decide which parts you can own, review the written scope, and check that at least two people can perform each recovery step.
What ongoing work remains after OpenBao auto-unseal goes live?
Auto-unseal reduces manual unsealing but does not end operations. Recurring work includes recovery key rotation, version upgrades, periodic restore and recovery drills, key store credential rotation, and review of who holds custodian roles. Recovery key handling needs a documented procedure that names custodians, storage locations and the steps for rotation after staff changes. Each version upgrade needs a check that the seal plugin or key store integration supports the target OpenBao release, so review the OpenBao release notes before scheduling. Ask whether the scope includes runbooks and whether a support retainer is needed, since DeployOpen offers ongoing support, upgrades and continuous testing as retainers.
Which auto-unseal method should we pick: HSM, KMIP or cloud KMS?
The right choice depends on where your keys must live, what your auditors accept, and which key store you already operate. A PKCS#11 HSM suits organizations that require keys held in dedicated hardware they control. KMIP fits environments where a key management server already exists. Cloud KMS seals fit teams running OpenBao in a cloud account that already manages keys with that provider. Since OpenBao 2.6.0, external KMS plugins extend the options, so confirm that the plugin for your key store supports the release you plan to run. Ask each candidate option how the cluster behaves when the key store is unreachable, because that behavior determines your recovery design.
Why does migrating from Shamir unsealing need extra planning?
Moving from Shamir unsealing changes how the cluster recovers, so the migration must be planned as a cutover on existing data. The migration guide describes in-place replacement of the server process on all nodes, with configuration, endpoints and URLs unchanged, but auto-unseal adds seal configuration and recovery key handling on top of that. Clusters bootstrapped before Vault 1.3 may need a rekey before moving to OpenBao. The guide also states that disable_mlock must be removed from configuration, since OpenBao 2.0.0 stopped using mlock. The migration guide was tested only against Vault 1.14.1 community edition, so confirm your starting version and edition before planning. Ask for a rollback plan and a rehearsal on a copy of production data.
How DeployOpen scopes and delivers OpenBao auto-unseal
DeployOpen scopes OpenBao auto-unseal as a fixed-scope engagement in your own infrastructure, covering the seal type, key custody, recovery key handling and the clusters that depend on it. Work is agreed in writing before the build starts, and ongoing support is available as a retainer. Each step is documented so your own team can operate the unseal path after handover.
How we scope
- Seal options checked against your hosting model: PKCS#11 HSM, KMIP or cloud KMS.
- Written scope names the OpenBao version, storage backend, HA topology and the clusters being unsealed.
- Scope sets who holds recovery keys, how they are split, and who approves a recovery.
How we build
- Build the seal configuration in a non-production cluster first, then test failover and restart behavior.
- Verify the seal key path: HSM or KMS connectivity, IAM or client certificate permissions and key policy.
- Test a node restart and a full cluster restart to confirm unattended unsealing works.
How we hand over
- Runbook covering seal provider outages, key rotation, recovery key ceremonies and node replacement.
- Migration notes for moving an existing Shamir-unsealed cluster, including any rekey steps it requires.
- Documented configuration, evidence of tests run, and a list of items your team must confirm.
How we support
- Optional retainer covers upgrades, seal provider changes and periodic restart and recovery drills.
- Seal configuration and plugin compatibility are reviewed after each OpenBao release you adopt.
- Retainer scope, including what is covered and how requests are handled, is written before service starts.
