Start from default deny and open only the traffic the lifecycle actually needs.

The operator treats network policy as part of the security model, not as an optional hardening layer. OpenBao Pods and lifecycle jobs begin from explicit allowlists, and the allowed traffic should line up with clustering, management, and the integrations the cluster is deliberately configured to use.

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

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.

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.