Vault on OpenShift: one Linux capability, four objects, and an SCC resolver that ignores your RBAC

The capability itself is the easy half: add it to a custom SCC and move on. The resolver is what eats the afternoon. OpenShift decides which SCC admits a pod, and when two candidates share a priority it chooses by an ordering the author describes as deterministic but not obvious ^[13]. In this cluster an unrelated `odf-blackbox-scc` sat at the same default priority of 10, and the init container was admitted under it and failed, even though the `vault` service account was bound to the new `vault-ipc-lock` SCC ^[14]. The RBAC that every walkthrough tells you to write is necessary and not sufficient ^[19]. What steers the decision is the container asking for `IPC_LOCK` in its own securityContext, which pushes the resolver toward an SCC that advertises it ^[15], and the author reports that hint is required even with `defaultAddCapabilities` set, because otherwise the resolver may never reach the SCC you wrote ^[16].

The two error messages are worth committing to memory, because only one of them mentions Vault. Vault needs `IPC_LOCK` to call `mlockall()` so secrets are not swapped to disk, and exits at startup without it ^[5]. On the upstream image it gets that far: `mlockall()` returns `EPERM` and the process exits saying it requires the capability ^[8]. On the Red Hat partner image the binary carries `cap_ipc_lock+ep` from `setcap`, the kernel drops it from the bounding set at exec time, and `exec()` fails with `operation not permitted` before Vault starts ^[9]. Same cause, unrecognisable symptoms ^[10]. The author moved to the upstream `docker.io/hashicorp/vault-enterprise:2.0.1-ent` ^[17].

Count the surface area. Granting a single Linux capability takes four artifacts: the SCC, a ClusterRole that custom SCCs do not get for free ^[12], a RoleBinding, and the capability entry in Helm values ^[18]. Two of them are cluster-scoped, which is why the deployment is assembled as three ArgoCD sources, with raw manifests carrying the SCCs, Routes and ConfigMaps the chart cannot cleanly own ^[4], and why a namespace-scoped team cannot land this alone ^[22].

That boundary predicts the rest of the writeup. The other three areas the author names are the auto-unseal token flow, Raft quorum during rolling updates, and a reconciliation bug in Vault Secrets Operator ^[3], and none of them are chart-owned state either: a credential to an external system, consensus that has to survive pod replacement, and someone else's reconcile loop ^[20]. Delegating unseal to HCP Vault's transit engine is the clearest case, since each pod's path to serving traffic now runs through a secret the cluster does not mint ^[21]. The claim that this is a straightforward combination of well-documented features ^[2] holds for each feature read on its own. The traps sit in the seams, and the seams are exactly what no single set of docs owns.