Choose how traffic reaches the service before you optimize the edge.

OpenBao can be exposed through Gateway API, Ingress, or a direct L4 Service. The important decision is not just which Kubernetes resource you use, but where TLS terminates, who owns certificate lifecycle, and whether the edge path matches the production posture you actually want to operate.

Decision matrix

Choose the access path deliberately

Choose the access path deliberately.

Path	Use it when	What the operator creates	Watch for
Gateway API	You want the strongest long-term edge model, clearer multi-tenancy, and first-class passthrough support.	Routes and supporting integration objects for the configured mode.	Controller feature support still matters, especially for TLSRoute and BackendTLSPolicy.
Ingress	You already have an ingress controller path and only need standard Kubernetes ingress semantics.	An Ingress resource targeting the public OpenBao Service.	This is usually a termination-oriented model and is less expressive than Gateway API for shared-platform routing.
Direct Service exposure	You want the simplest L4 path, often through a cloud load balancer or private network boundary.	A LoadBalancer or NodePort-style Service configuration.	You own more of the perimeter behavior yourself and lose the richer route-level policy surface.

Decision matrix

Where TLS should terminate

Where TLS should terminate.

Pattern	Use it when	Why it fits or does not fit
Passthrough	You want OpenBao to remain the TLS endpoint and preserve end-to-end certificate identity.	This is the cleanest production default because the application keeps control of the server certificate and private key usage.
Edge termination with backend TLS	You need HTTP-aware controls, policy enforcement, or centralized certificate handling at the edge.	This is valid, but you must be explicit about how trust is re-established between the edge and OpenBao.
Temporary operator-managed trust	You are standing up a development or internal evaluation environment quickly.	This is convenient, but it is not the Hardened production contract and should not become the long-term default by inertia.

Diagram

Exposure paths

The service boundary is a choice between where traffic enters, where TLS terminates, and how much of the edge behavior the operator is expected to own.

Representative configurations

Gateway API

Configure

Expose OpenBao through Gateway API

yaml

spec:
gateway:
  enabled: true
  tlsPassthrough: true
  hostname: bao.example.com
  gatewayRef:
    name: main-gateway
    namespace: gateway-system

Start here when Gateway API is your edge standard. For most production clusters, use TLS passthrough unless you have a specific need for termination at the Gateway.

Ingress

Configure

Expose OpenBao with a standard Ingress

yaml

spec:
ingress:
  enabled: true
  host: "bao.example.com"
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

This is useful when you already operate an ingress-controller standard and do not need the richer Gateway API route model.

Service

Configure

Expose OpenBao directly through an L4 Service

yaml

spec:
service:
  type: LoadBalancer
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"

Use this when you want the simplest network boundary and your platform already treats a load balancer or private network edge as the primary perimeter.

Match the TLS mode to the exposure path

Reference table

TLS mode pairings

TLS mode pairings.

TLS mode	Good exposure fit	Why
External	Gateway passthrough, Ingress re-encryption, or direct Service exposure	This keeps CA ownership outside the operator and works cleanly with both internal and externally terminated edges.
ACME	Gateway passthrough or direct public exposure	OpenBao must remain the TLS endpoint to complete ACME challenge and certificate lifecycle correctly.
OperatorManaged	Development or internal evaluation paths only	This is easy to start with, but the operator becomes the certificate authority and that is not the Hardened production posture.

External TLS Secret contract

What `tls.mode: External` actually expects

For the cluster-facing TLS path, the operator reads fixed same-namespace Secret names:

• <cluster-name>-tls-ca with key ca.crt
• <cluster-name>-tls-server with keys tls.crt and tls.key

The server certificate must chain to the CA bundle and cover the internal service name openbao-cluster-<cluster-name>.local, plus any configured ingress hostname, gateway hostname, and spec.tls.extraSANs.

Do not confuse edge TLS Secrets with the cluster server TLS Secrets

spec.ingress.tlsSecretName only controls the Secret referenced by the managed Ingress resource. It does not rename the Secrets that the OpenBao Pods use for their own listener certificate and CA trust.

Traefik v3 backend trust

If you use Traefik v3 with backend TLS validation, configure a ServersTransport that trusts the generated CA Secret for the cluster. This is an implementation detail of the ingress path, not a reason to change the underlying TLS model.

Continue service boundary setup

Gateway API supportUse the detailed Gateway API page when Gateway is the primary edge path.Network configurationAlign ingress peers, DNS, API-server egress, and external service egress with the exposure path you chose.Unseal configurationUse the exact Secret and mounted-file contract page when external TLS and unseal credentials both depend on the same trust workflow.TLS and workload identityGo deeper on certificate ownership and trust boundaries when you need the security model behind these choices.