Network policy model

Default-deny posture for OpenBao Pods and lifecycle jobs, plus the ingress and egress paths the operator expects when cluster management and integrations are configured.

Diagram

OpenBao network perimeter

The workload path starts closed and only opens the traffic required for cluster management, Raft, ingress, and explicitly configured integrations.

Decision matrix

Network posture at a glance

Network posture at a glance.

Surface	Default posture	What opens it up
Workload ingress	Denied by default	Operator probes, Raft peer traffic, and explicit ingress peers through gateway or configured trusted peers.
Workload egress	Denied by default except for core cluster dependencies	API server, DNS, Raft peer traffic, and explicitly configured integrations.
Backup and restore job egress	Separate from the main workload policy	Explicit object-storage and identity reachability assumptions through job-level configuration.
Controller ingress	Restricted to health and metrics surfaces	Monitoring and kubelet probe paths only when operator network policies are enabled.

Workload traffic rules

Ingress

Reference table

Allowed ingress paths

Allowed ingress paths.

Source	Typical port	Why it exists
Operator	8200	Required for probes, initialization checks, and status-related interactions with the workload.
Raft peers	8201/TCP	Required for consensus, leader election, and replication between StatefulSet members.
Gateway or trusted ingress peer	8200	Allowed only when gateway integration or trusted ingress peers are configured deliberately.
Kube-system health paths	Platform-dependent	Some CNIs or DNS health checks require controlled access from system namespaces.

If you need additional ingress, use:

• spec.network.ingressRules for additive peer rules
• spec.network.trustedIngressPeers for user-managed ingress or passthrough proxies

Managed spec.ingress.enabled: true configurations must declare at least one trusted ingress peer so the OpenBao API listener is not opened to every pod that can reach the namespace.

Read replicas are client-serving Pods

When steady read replicas are enabled, the main client Service can route to both voter and read-replica Pods. That does not create a separate ingress policy surface by itself; the same cluster ingress rules still govern the client listener, and the optional dedicated read Service remains only a second Service object selecting the same client-serving port on the read pool.

Egress

Reference table

Allowed egress paths

Allowed egress paths.

Destination	Typical port	Why it exists
Kubernetes API	443	Required for service registration, status-related interactions, and controlled API assumptions.
CoreDNS	53/TCP+UDP	Required to resolve peers and configured external services.
Raft peers	8201/TCP	Required for replication and cluster membership traffic.
Object storage, KMS, PKI, or other integrations	Explicitly configured	These should only open when the corresponding feature is intentionally enabled.

Lifecycle jobs use separate egress assumptions

Backup and restore do not rely on the main workload policy alone. They use separate job identities and separate network assumptions, which is why BackupConfigurationReady and RestoreConfigurationReady exist as distinct status signals.

Steady read replicas are staged out of destructive workflows

Blue-green promotion and restore intentionally drain the steady read pool before destructive membership or snapshot work starts, then restore it before the workflow completes. That is a network and safety boundary as much as a rollout detail: destructive workflows do not keep a second permanent client-serving non-voter tier online while peer removal or snapshot replacement is in progress.

Status checkpoints for network assumptions

When manifests alone do not explain the observed behavior, start with these conditions:

• APIServerNetworkReady for API-server reachability assumptions
• GatewayIntegrationReady for gateway listener and controller compatibility
• BackupConfigurationReady for object-storage and backup auth reachability
• RestoreConfigurationReady for restore job egress and identity assumptions

Controller network posture

Reference table

Controller networking

Controller networking.

Surface	Posture	Why
Ingress	Restricted to metrics and kubelet probes when operator network policies are enabled.	The controller should not expose a broad incoming network surface.
Egress	Primarily the Kubernetes API and essential control-plane services.	Controller traffic should stay close to reconciliation and not behave like a general egress client.

Continue platform controls

Admission policiesSee how unsafe configuration and drift are blocked before they persist.RBAC architectureConnect network boundaries back to the split-controller identity model.Configure network settingsSwitch to the task page when you are ready to set ingress or egress rules on a real cluster.