OpenBao control groups for dual approval

A requester's call to a path covered by a control group policy is held until an approver acts on it. As we read the OpenBao documentation, the lifecycle has four steps: the call is held, an approver is identified, approval or denial is recorded, and the outcome returns to the requester. Each step below is marked where the behavior must be confirmed against the 2.7.0 documentation before your design depends on it. Treat those marks as a test plan for a staging cluster, not as settled behavior.

Step 1 and 2: hold and identify. Confirm what the requester receives when the call is held, such as a status code, a handle or a token that must be presented again later. Confirm how an approver learns that a request is waiting. OpenBao does not send approver notifications, so the approver is found by polling or by a notification path you build. Confirm whether the approver set is defined in the policy stanza itself and whether a group or entity can be referenced there. Plan the notification path before go-live, because an approval that nobody sees leaves the workflow stalled.

Approver identity and separation. The approver must authenticate to OpenBao as a distinct identity from the requester. Confirm which identity types the 2.7.0 control group logic accepts, such as entities, aliases or tokens, and whether two tokens issued to the same person count as two approvers. Check separation in both directions: the requester's policy must not allow the approval action, and the approver's policy must not allow the original read of the secret. Verify this with two separate test accounts before any production policy is written.

Release, denial and expiry. Confirm whether an approved request is replayed automatically or whether the requester must repeat the original call, and how long an approval stays valid. Confirm the behavior on denial and on expiry, since a requester who is told nothing will retry in ways that create noise. Decide who may approve outside business hours and whether any break-glass path sits outside the control group. Finally, check that each approval and denial, along with the approver's identity, appears in the audit log, because that log is the evidence that a second person approved the release.

OpenBao does not notify approvers when a control group request is waiting, so your team has to build a channel that tells the right people a request needs their action. Without one, a request can sit unseen until the requester chases someone by hand, and a dual approval control only protects the secret if approvers respond in a reasonable time. Decide before the build starts who owns this channel, which approver groups it must reach, which chat or ticket system they already watch, and what happens when a request goes unanswered. Treat the notification as a convenience layer on top of the control group, never as the approval itself. The approval still has to be recorded by an authorized identity inside OpenBao.

Three general designs are worth comparing. The simplest is polling: a scheduled job queries the pending control group requests and posts any new ones to the approver channel. A second design is a watcher that reads OpenBao's audit output, so it reacts to the events the cluster already records and can be checked against the audit trail. A third design watches request state directly through the control group interface and compares it with what it has already announced. Polling is easy to reason about but adds latency equal to its interval. Audit-driven watchers give a clearer record of what was sent, but they depend on the audit devices running and on the event fields you can parse. Each design needs a deduplication step so approvers are not flooded with repeats for the same request.

The main risk is putting approval details into notifications. Chat channels and ticket systems are usually retained for long periods, searchable by many people, and copied into other tools, so a message that names the secret path, the requester, and the target system can leak operational detail to people who should not see it. Keep the message to what an approver needs to decide: a request identifier, the approver group, the time it was raised, and a link that opens the request only after the approver authenticates to OpenBao. Do not place secret values, tokens or wrapping details in any message. Plan for lookalike messages as well, because an attacker who can post in the channel can imitate a genuine request, so approvers should verify each request inside OpenBao before acting on it.

Confirm the exact integration against the audit and control group interfaces of the OpenBao version you run, since the control group stanza was added in 2.7.0 and later patch releases may change the fields and endpoints involved. Ask the implementation team to demonstrate which request states and audit events are available, what the audit output contains for a waiting request, and whether a request can be listed by approver group. Give the watcher its own identity with the narrowest policy that allows it to read pending requests, and monitor the watcher itself, because a silent failure means approvers are never told. Test the full path with a non-production request, including a missed notification, a duplicate, and a request that expires without approval. Assign an owner for the watcher's code, its credentials and its upgrades.

Before any production secret or certificate sits behind a control group, run a test plan that shows the gate works as written. Treat the plan as five pass or fail cases, each tied to a requirement in your policy design: a requester can trigger the hold, an unauthorized identity cannot approve, the designated approvers can approve or deny, a denied request does not release the secret, and every step appears in the audit trail. Run the plan on a non-production OpenBao cluster that uses the same version, the same control group stanza and the same approver identity source as production. Record the OpenBao version, the policy version and the identity used for each run, so a failed case can be traced to the exact configuration that produced it.

The first two cases test the hold itself. Use a requester identity that has read access to the target path and confirm that the read returns the waiting state instead of the secret value. Check that the pending request is visible to the approvers, and that the requester cannot obtain the value through a second read, a different token or a repeated request. The unauthorized case needs more care. Attempt approval with an identity outside the approver set, including a teammate of the requester, an operator with broad administrative rights and any service identity near the workflow. Each attempt should fail and the failure should be recorded. If an identity you did not expect can approve, stop and review the policy before going further.

The approver cases confirm that the people you named can act on the hold. Each designated approver should approve one request and deny another, in separate runs, so you can see both outcomes. Confirm that approval releases the secret only after the number of approvals the policy requires has been met, and that a single approval does not release it when two are needed. Compare the approver list in the policy with the roles your change records say should hold that authority. A mismatch found in a test cluster is far cheaper to fix than one found after release. Also confirm that a requester cannot approve their own request, since self-approval is a common gap in dual approval designs.

A denied request must leave the secret locked. After a denial, have the requester retry retrieval with the same token and again after a fresh login, and confirm that neither attempt returns the value. Repeat the check after the request expires if your policy sets an expiry, because an expired hold should also fail closed. Review response bodies as well as status codes, and make sure test output does not write the secret to a log file or terminal history. Use a clearly marked dummy secret for these runs so that a leak in the test harness cannot expose production material.

The last case confirms that events are recorded. Enable the audit devices you plan to use in production and check that the request, each approval, each denial and each retrieval attempt appear with the identity and timestamp. Confirm that sensitive values are hashed or absent in those entries, consistent with your audit configuration. Because OpenBao does not send approver notifications, test the notification process you build separately and record it as its own case. Keep the scripts, inputs, outputs, versions and dates from every run together as evidence. Repeat the full plan after each OpenBao upgrade and after any policy change. Retained results support a compliance review, but they do not pass one; an independent auditor decides what the evidence shows.