Security: OpenBao Operator

This section provides a comprehensive security overview for the OpenBao Operator, covering the security model, RBAC architecture, and threat analysis.

Security Model Overview

The security model relies on a Supervisor Pattern, where the operator orchestrates security-critical configuration (TLS, unseal keys, network policies) from the outside, while delegating data plane security to OpenBao itself.

Secure by Default

The Operator enforces a "Secure by Default" posture:

• Non-Root Execution: Operator and OpenBao pods run as non-root users
• Read-Only Filesystem: OpenBao pods use read-only root filesystem
• Network Isolation: Automatic NetworkPolicies enforce default-deny ingress
• Least-Privilege RBAC: Split-controller design with minimal permissions
• Supply Chain Security: Optional Cosign image verification

Tenancy Security Models

• Multi-Tenant (Zero Trust): The Controller is untrusted. It cannot read Secrets and must request permissions via the Provisioner. This creates a hard security boundary between tenants.
• Single-Tenant (Direct Admin): The Controller is fully trusted within its namespace. It has ClusterRole permissions bound to that specific namespace, simplifying operations but removing the Zero Trust isolation.

Security Topics

• Fundamentals

  ---

  Threat model, profiles, and secrets management.

  Threat Model

  Profiles

  Secrets

• Infrastructure

  ---

  RBAC, Admission Policies, and Network Security.

  RBAC

  Policies

  Networking

• Workload

  ---

  Pod security, TLS, and Supply Chain.

  Pod Security

  TLS

  Supply Chain

• Multi-Tenancy

  ---

  Namespace isolation and tenant boundaries.

  Tenant Isolation

See Also

• User guide: Security Profiles
• User guide: Security Considerations
• User guide: Multi-Tenancy
• User guide: Production Checklist