Boundary OpenShift Helm charts
You can deploy Boundary on Red Hat OpenShift using two separate Helm charts. The controller chart installs Boundary's control plane components, and the worker chart installs self-managed data plane workers that proxy session traffic.
These are the same Helm charts you use to deploy Boundary on Kubernetes, with an additional openshift value group. Set openshift.enabled=true to render OpenShift Route resources, apply a security context that complies with OpenShift security context constraints (SCCs), and resolve images from the Red Hat certified registry. Routes do not change the configured Service types, so set externally exposed Services to ClusterIP when you want Routes to be the only external paths. When openshift.enabled=false, both charts ignore every value under openshift and behave exactly as they do on Kubernetes. For general Kubernetes deployment guidance, refer to Boundary Helm charts.
Boundary uses separate charts for controllers and workers because they have different lifecycle, scaling, persistence, and exposure requirements. The charts use the official hashicorp/boundary-enterprise image by default, or the Red Hat UBI (Universal Base Image) build from registry.connect.redhat.com when openshift.enabled=true.
The Boundary Helm charts are not compatible with Helm 2. You must use Helm 3 or later, and a Red Hat OpenShift cluster running version 4.19 or later.
Boundary architecture
Boundary uses a distributed architecture:
- Controllers manage authentication, authorization, session coordination, worker registration, and API/UI access.
- Workers proxy session traffic between clients, upstream workers, and target systems.
A Boundary controller deployment requires a PostgreSQL database, a Boundary Enterprise license, key management system (KMS) configuration, and a Secret containing the values required by the rendered HCL and enabled bootstrap Job. A worker deployment requires a valid worker HCL configuration and a registration model. The worker deployment may also need persistent storage if the selected worker authentication or recording configuration requires it.
Controllers and workers that must be reachable from outside the cluster are exposed through Routes rather than LoadBalancer Services. Examples include the controller's cluster listener for external workers or a worker's proxy listener for client sessions. Routes share the router's HTTPS port (443 by default), so public_cluster_addr and public_addr must reference that port instead of the chart's internal listener ports.
Chart resources and models
The charts package OpenShift resources and Helm release workflows. They do not replace the Boundary runtime configuration.
| Chart | Role | Primary OpenShift resources | State model |
|---|---|---|---|
| Boundary controller | Control plane | Deployment, Services, ConfigMaps, PodDisruptionBudget, hook Jobs, and enabled API, cluster, and operations Routes | Controller pods are stateless. Controller state lives in PostgreSQL. Database initialization and administrator bootstrap Jobs are enabled by default. |
| Boundary worker | Data plane | Deployment, Services, ConfigMap, enabled proxy and operations Routes, and PersistentVolumeClaims when auth or recording persistence is enabled | Enabled PVCs can persist worker identity and optional session recordings. |
Controller chart
The controller chart is intended for operator-managed Boundary control planes on OpenShift. It can run multiple controller replicas and uses Helm hook Jobs for database initialization and administrator bootstrap by default. It can also run optional database migration and repair Jobs during upgrades.
You must provide any required external dependencies such as PostgreSQL, KMS access, Boundary Enterprise license data, and TLS material, if necessary.
Set openshift.enabled=true to render the controller's API, cluster, and ops Routes, and to apply an SCC-compliant security context to the controller Deployment and its hook Jobs.
Worker chart
The worker chart installs one self-managed Boundary worker per Helm release. It is focused on egress and intermediate worker use cases, including workers used with HCP Boundary or self-managed Boundary deployments.
The worker chart mounts the worker HCL you provide in worker.config, exposes optional proxy and operations services, and provisions optional PVCs for auth storage and session recording storage.
Set openshift.enabled=true to publish the worker's proxy listener through a Route and apply an SCC-compliant security context to the worker Deployment. Set worker.service.proxy.type=ClusterIP when you do not also want the default LoadBalancer Service.
Shared configuration model
The Boundary Helm charts separate configuration into two layers:
- Boundary runtime configuration supplied as HCL through a chart value.
- OpenShift infrastructure configuration supplied through Helm values, including the
openshiftvalue group.
The charts do not infer all runtime settings from the OpenShift values. You must align listener ports, addresses, storage paths, TLS settings, and registration settings between the Boundary HCL and the OpenShift resources created by the charts. In particular, public_cluster_addr and public_addr must match the Route hostname and port 443 when a Route is enabled, not the chart's internal Service name and port.
Next steps
Refer to the following topics for next steps:
- To deploy controllers, refer to Deploy controllers on OpenShift using a Helm chart.
- To deploy workers, refer to Deploy workers on OpenShift using a Helm chart.
More information
- For supported Helm values, refer to the following topics:
- To view example configurations, refer to the following topics: