Skip to content

Enterprise Deployment Architecture

cloudtaser's enterprise deployment model uses the CLI as an orchestrator that bridges the gap between OpenBao (secret source) and Kubernetes clusters (targets). OpenBao never needs WAN exposure. The plan file is the only artifact that moves between environments.

The Problem

Enterprise environments have constraints that prevent simple OpenBao-to-cluster connectivity:

  • Air-gapped networks. OpenBao is in a secure EU network segment. Target clusters may be in different VPCs, clouds, or even on-premises.
  • No direct WAN access. Security teams prohibit exposing the OpenBao endpoint to the internet or to cross-cloud peering.
  • Multi-cluster deployments. A single OpenBao instance serves dozens of Kubernetes clusters across regions and cloud providers.
  • Separation of duties. The platform team manages OpenBao, the security team reviews changes, and application teams own their workloads.

CLI-as-Orchestrator Model

The cloudtaser CLI runs on an operator's workstation (or in a CI/CD runner) and acts as the bridge. It connects to each system independently -- it never requires OpenBao and the cluster to be able to reach each other at plan time.

                     Operator Workstation
                     (or CI/CD runner)
                            |
              +-------------+-------------+
              |                           |
     cloudtaser-cli source *          cloudtaser-cli target *
              |                           |
              v                           v
    +-------------------+      +--------------------+
    |  EU Vault/OpenBao |      |  Target Kubernetes |
    |  (private network)|      |  Cluster           |
    +-------------------+      +--------------------+

The CLI connects to OpenBao for source commands and to the Kubernetes cluster for target commands. The plan file is the handoff artifact:

  1. target discover -o plan.yaml -- connects to the cluster, writes a plan file
  2. Security team reviews plan.yaml -- no system access needed, just a YAML file
  3. source apply-plan plan.yaml -- connects to OpenBao, creates policies and roles
  4. User populates secrets in OpenBao -- uses bao/vault CLI or UI
  5. source verify-plan plan.yaml -- connects to OpenBao, checks secret existence
  6. target protect --plan plan.yaml -- connects to the cluster, patches workloads

Steps 1 and 6 only need cluster access. Steps 3 and 5 only need OpenBao access. Step 2 needs nothing. This means:

  • OpenBao never needs to be reachable from the cluster network during the plan workflow.
  • The plan file can be transferred between networks via secure file transfer, Git, or even email.
  • Different people can execute different steps from different machines.

Air-Gap Friendly Design

In fully air-gapped environments, the workflow adapts naturally:

  Network A (cluster)          Secure Transfer          Network B (vault)
  =====================        ==============          ===================

  target discover -o plan.yaml
            |
            v
        plan.yaml  ----------->  plan.yaml
                                      |
                                      v
                              source apply-plan plan.yaml
                              (populate secrets)
                              source verify-plan plan.yaml
                                      |
                                      v
        plan.yaml  <-----------  plan.yaml (unchanged)
            |
            v
  target protect --plan plan.yaml

The plan file is the only thing that crosses the air gap. It contains no secret values -- only metadata about which workloads need which OpenBao paths. It is safe to store in version control or compliance systems.

Multi-Cluster Topology

A single EU OpenBao can serve multiple Kubernetes clusters. Each cluster gets its own plan file:

                          EU Vault / OpenBao
                         (single source of truth)
                                  |
                    +-------------+-------------+
                    |             |             |
              apply-plan    apply-plan    apply-plan
              verify-plan   verify-plan   verify-plan
                    |             |             |
                    v             v             v
             +----------+  +----------+  +----------+
             | Cluster A |  | Cluster B |  | Cluster C |
             | (GKE EU)  |  | (EKS EU)  |  | (AKS EU)  |
             +----------+  +----------+  +----------+
                    |             |             |
              discover -o   discover -o   discover -o
              protect       protect       protect
              --plan        --plan        --plan

Each cluster generates its own plan. All plans point to the same OpenBao. OpenBao policies and roles are per-tenant (per-namespace), so clusters can share OpenBao paths or have isolated paths depending on the naming convention.

Per-cluster workflow

# Cluster A
cloudtaser-cli target discover --kubeconfig ~/.kube/cluster-a -o plan-a.yaml
cloudtaser-cli source apply-plan plan-a.yaml --openbao-addr https://vault.eu.example.com --token hvs.TOKEN
# (populate secrets, verify)
cloudtaser-cli target protect --plan plan-a.yaml --kubeconfig ~/.kube/cluster-a --secretstore-address https://vault.eu.example.com --interactive

# Cluster B
cloudtaser-cli target discover --kubeconfig ~/.kube/cluster-b -o plan-b.yaml
cloudtaser-cli source apply-plan plan-b.yaml --openbao-addr https://vault.eu.example.com --token hvs.TOKEN
# (populate secrets, verify)
cloudtaser-cli target protect --plan plan-b.yaml --kubeconfig ~/.kube/cluster-b --secretstore-address https://vault.eu.example.com --interactive

Plan File as Compliance Artifact

The migration plan is designed to be reviewed and approved before execution:

Property Benefit
Human-readable YAML Security teams can review without CLI access
No secret values Safe to store in Git, Jira, or compliance platforms
Versioned schema apiVersion: cloudtaser.io/v1 ensures forward compatibility
Audit fields createdAt, createdBy, cluster provide provenance
Status tracking Each workload's migration status is recorded in the file

Typical compliance workflow:

  1. Platform team generates the plan and opens a review ticket
  2. Security team reviews OpenBao paths, field mappings, and tenant boundaries
  3. Security team approves the plan (the YAML file is the approval artifact)
  4. Platform team executes apply-plan, populates secrets, runs verify-plan
  5. Application team confirms readiness
  6. Platform team executes target protect --plan with interactive approval
  7. The final plan file (with all statuses set to migrated) is archived as evidence

Interactive vs Automated Migration

The target protect --plan command supports two modes:

Interactive (--interactive)

Each workload is presented with its full secret mapping. The operator confirms injection and rolling restart individually. Recommended for:

  • First migration of production workloads
  • Environments where application teams need to confirm each workload
  • Regulated environments requiring per-workload approval

Auto-approve (--yes)

All workloads are migrated without prompting. Recommended for:

  • CI/CD pipelines
  • Development and staging environments
  • Re-running after a partial migration where remaining workloads are already approved

Both modes are resumable. If interrupted, re-run the same command -- workloads already marked as migrated or skipped are not reprocessed.

Runtime Connectivity

While the plan workflow does not require OpenBao-to-cluster connectivity during migration setup, the workloads themselves need OpenBao access at runtime. Once cloudtaser annotations are applied and pods restart:

  1. The cloudtaser init container injects the wrapper binary
  2. The wrapper authenticates to OpenBao using the pod's ServiceAccount JWT (Kubernetes auth)
  3. The wrapper fetches secrets from OpenBao into process memory
  4. The wrapper fork+execs the original process with secrets in the child environment

This means the OpenBao endpoint must be reachable from the cluster's pod network at runtime. cloudtaser supports three connectivity models:

Beacon Relay (default)

The beacon relay is the default and recommended connectivity mode. Both OpenBao (bridge) and the cluster (broker) connect outbound to a stateless beacon relay on TCP 443. The beacon matches them by info hash and relays encrypted mTLS traffic. Neither side needs inbound ports or a public endpoint.

  • Zero-config -- only outbound TCP 443 required from both sides
  • Full NAT traversal -- works behind any firewall or NAT
  • Stateless relay -- the beacon holds no secrets and cannot decrypt traffic

See Beacon Relay Connectivity for the full design, security properties, and deployment instructions.

Reverse Connect

For deployments where you can expose a LoadBalancer on the cluster and want to avoid the extra hop through the beacon, the reverse-connect model is an alternative. In this model:

  • The OpenBao server runs a bridge component that connects outbound to a broker inside the cluster
  • The wrapper fetches secrets through the in-cluster broker, which proxies requests through the bridge to OpenBao
  • OpenBao has zero inbound attack surface -- no ports open, no ingress traffic
  • The OpenBao operator controls the connection by starting or stopping the bridge

See Reverse-Connect Architecture for the full design, security properties, and deployment instructions.

Direct Connect

The wrapper connects directly to the OpenBao endpoint. This is the simplest model, suitable when OpenBao is in the same network or reachable via private connectivity:

  • Private peering between OpenBao VPC and the cluster VPC
  • VPN or WireGuard tunnel for cross-cloud connectivity
  • Internal load balancer if OpenBao is in the same cloud region
  • Ingress with mTLS for external access with client certificate authentication

Configuring runtime connectivity

The cloudtaser-cli target connect command configures the Kubernetes auth method in OpenBao to accept ServiceAccount JWTs from the target cluster. This works with both direct and reverse-connect models.