IBM contributor maps four Vault deployment patterns on OpenShift

An IBM Community engineering post published August 30 lays out four ways to run Vault on Red Hat OpenShift: Helm or the Vault Secrets Operator, each split into development and production configurations. The accompanying repository supplies shell scripts, a side-by-side resource table and installation and deletion paths.

What the guide separates

The development variants deliberately keep the footprint small. The Helm path uses one dev-mode pod without persistent storage, while the Operator path uses a single-node Raft deployment with a 2 GiB persistent volume. The repository labels both as test or development configurations rather than production topologies.

The two production variants converge on a more substantial baseline: three Vault replicas, integrated Raft storage, TLS and 45 GiB of total persistent storage across data and audit volumes. The Helm path enables the agent injector and defines a disruption budget; the Operator path instead uses VaultConnection and VaultAuth custom resources and configures Kubernetes authentication, according to the project comparison.

That distinction is the useful part for OpenShift teams. Helm keeps lifecycle control close to charts and the CLI. The Operator route expresses more of the Vault connection and authentication model through Kubernetes resources. The guide does not make those approaches interchangeable; it exposes their different prerequisites and operating surfaces.

The implementation boundary

The scripts assume an existing vault namespace, an IBM entitlement key and an authenticated oc session. Production examples also assume three worker nodes and the ocs-storagecluster-ceph-rbd storage class. The Operator examples require the Vault Secrets Operator and its custom resource definitions to be installed, while the Helm examples require the Helm CLI and HashiCorp chart repository.

The repository also includes configuration paths for KV secrets, database credentials, certificates and transit encryption, plus an example MariaDB deployment. A migration section distinguishes same-cluster transfers performed through oc exec from cross-cluster transfers using the Vault CLI and reachable HTTPS endpoints.

What teams should validate

This is a contributor guide and script collection, not a Red Hat product support statement. Before adapting it, platform teams should verify image entitlements, storage classes, certificate handling, network policies, audit retention and disaster recovery against their own supported OpenShift and Vault versions. The repository itself warns against storing real tokens in source and recommends protecting root and unseal material outside the cluster.

Used that way, the project is a concrete lab for comparing the day-one mechanics of chart-managed and Operator-integrated Vault on OpenShift—without mistaking a runnable example for a complete production design.