CLI Reference¶

The cloudtaser-cli binary is a command-line tool for deploying, configuring, validating, and troubleshooting cloudtaser. It runs on-demand and does not require a persistent process.

Current version: v0.17.30

Compliance note

cloudtaser-cli target audit generates compliance evidence. cloudtaser-cli target validate verifies protection coverage.

Leadership note

The CLI provides discovery, migration, validation, and audit capabilities for the full cloudtaser lifecycle.

Installation¶

macOS (Homebrew)Direct downloadContainer

brew install cloudtaser/tap/cloudtaser-cli

Download the binary for your platform from releases.cloudtaser.io:

# macOS (Apple Silicon)
curl -sL https://releases.cloudtaser.io/cli/v0.17.30/cloudtaser-cli-darwin-arm64 \
  -o /usr/local/bin/cloudtaser-cli && chmod +x /usr/local/bin/cloudtaser-cli

# macOS (Intel)
curl -sL https://releases.cloudtaser.io/cli/v0.17.30/cloudtaser-cli-darwin-amd64 \
  -o /usr/local/bin/cloudtaser-cli && chmod +x /usr/local/bin/cloudtaser-cli

# Linux (x86_64)
curl -sL https://releases.cloudtaser.io/cli/v0.17.30/cloudtaser-cli-linux-amd64 \
  -o /usr/local/bin/cloudtaser-cli && chmod +x /usr/local/bin/cloudtaser-cli

# Linux (ARM64)
curl -sL https://releases.cloudtaser.io/cli/v0.17.30/cloudtaser-cli-linux-arm64 \
  -o /usr/local/bin/cloudtaser-cli && chmod +x /usr/local/bin/cloudtaser-cli

Available platforms: darwin-amd64, darwin-arm64, linux-amd64, linux-arm64

docker run --rm -v ~/.kube:/root/.kube ghcr.io/cloudtaser/cloudtaser-cli:latest target status

Commands¶

Note on http:// vs https://

All examples below use https:// for the secret store address. Plain http:// is supported only when the secret store endpoint binds to loopback (e.g., dev-mode OpenBao at http://127.0.0.1:30200) and is reachable only within the same node. Production deployments MUST use TLS.

Flag naming: --secretstore-* is canonical

Every --secretstore-<suffix> flag shown below has a --vault-<suffix> alias that still works - both accept the same value. The --vault-* names are kept for backward compatibility and will be removed in Phase 3 of the rename (tracked in cloudtaser-operator#228). New scripts and runbooks should use --secretstore-* exclusively.

target connect¶

Connect a Kubernetes cluster to an external secret store (OpenBao or HashiCorp Vault). Extracts cluster details from the current kubeconfig and configures the secret store with Kubernetes auth so that pods can authenticate and retrieve secrets.

This command performs three steps:

Creates a ServiceAccount and ClusterRoleBinding in the cluster for secret-store token review
Enables and configures the Kubernetes auth backend in the secret store
Creates a secret-store role (and optionally a policy) for pod authentication

The secret store must be reachable from the machine running the CLI, and the K8s API endpoint must be reachable from the secret store for TokenReview API calls.

cloudtaser-cli target connect \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token hvs.EXAMPLE

Flag	Description	Required	Default
`--secretstore-address`	Secret store address (e.g. OpenBao / HashiCorp Vault)	Yes	--
`--secretstore-token`	Secret store token with admin privileges	Yes	--
`--kube-endpoint`	Override K8s API endpoint URL	No	from kubeconfig
`--auth-path`	Secret store auth method mount path	No	`kubernetes`
`--secretstore-role`	Secret store role name to create	No	`cloudtaser`
`--namespaces`	Comma-separated namespaces to allow	No	all
`--secret-paths`	Comma-separated KV v2 paths for the policy	No	--
`--dry-run`	Print what would be done without making changes	No	`false`

Connect with specific namespacesOverride K8s endpointDry run

cloudtaser-cli target connect \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token hvs.EXAMPLE \
  --namespaces default,myapp \
  --secret-paths "secret/data/*"

cloudtaser-cli target connect \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token hvs.EXAMPLE \
  --kube-endpoint https://k8s.example.com:6443

cloudtaser-cli target connect \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token hvs.EXAMPLE \
  --dry-run

target discover¶

Scan Deployments, StatefulSets, and DaemonSets for secret references (secretKeyRef, secretRef, envFrom with secret references, and third-party secret-store injector annotations - e.g. Vault Agent Injector). Generates SecretMapping CRD YAML to stdout for each workload that can be piped to kubectl apply.

With --output-plan (-o), generates a MigrationPlan YAML file instead of SecretMapping CRDs. The plan file groups workloads by namespace as tenants and maps K8s secret references to suggested secret-store paths. When using -o, the --secretstore-address and --secretstore-role flags are not required.

Workloads already annotated with cloudtaser.io/inject: "true" are skipped. System namespaces (kube-system, kube-public, kube-node-lease) are excluded.

cloudtaser-cli target discover -o plan.yaml

Flag	Description	Required	Default
`--secretstore-address`	Secret store address for generated SecretMapping CRDs	Yes (unless `-o`)	--
`--secretstore-role`	Secret store role for generated SecretMapping CRDs	Yes (unless `-o`)	--
`-o`, `--output-plan`	Write a MigrationPlan YAML to the given path	No	--
`--kubeconfig`	Path to kubeconfig file	No	`~/.kube/config`
`-n`, `--namespace`	Namespace to scan	No	all namespaces

Generate a migration planGenerate plan for a specific namespaceGenerate plan with a custom kubeconfigDiscover and apply (SecretMapping CRDs)Discover in a specific namespace (SecretMapping CRDs)

cloudtaser-cli target discover -o plan.yaml

cloudtaser-cli target discover -n production -o plan.yaml

cloudtaser-cli target discover \
  --kubeconfig ~/.kube/staging -o plan.yaml

cloudtaser-cli target discover \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-role my-app | kubectl apply -f -

cloudtaser-cli target discover -n production \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-role my-app | kubectl apply -f -

See Migration Plan Workflow for the full plan-based workflow and Plan File Format for the YAML schema.

target status¶

Show the status of cloudtaser components in the cluster (operator, webhook, eBPF agent) and report workload protection coverage.

System namespaces (kube-system, kube-public, kube-node-lease) are excluded from workload counts.

cloudtaser-cli target status

Flag	Description	Required	Default
`--kubeconfig`	Path to kubeconfig file	No	`~/.kube/config`
`-n`, `--namespace`	Namespace to check	No	all namespaces

Full cluster statusSpecific namespaceCustom kubeconfig

cloudtaser-cli target status

cloudtaser-cli target status -n production

cloudtaser-cli target status --kubeconfig ~/.kube/staging

target validate¶

Perform live validation checks against the Kubernetes cluster and the secret store to verify that cloudtaser is correctly deployed and configured.

Checks performed:

Kubernetes cluster connectivity
cloudtaser operator deployment
Mutating webhook configuration
Secret store health and seal status (OpenBao/HashiCorp Vault)
Kubernetes auth method registered in the secret store (if token provided)
Count of protected workloads
Count of unprotected workloads referencing K8s Secrets
eBPF daemonset status

cloudtaser-cli target validate \
  --secretstore-address https://vault.eu.example.com

Flag	Description	Required	Default
`--secretstore-address`	Secret store address (e.g. OpenBao / HashiCorp Vault)	Yes	--
`--secretstore-token`	Secret store token (optional -- enables auth method checks)	No	--
`--kubeconfig`	Path to kubeconfig file	No	`~/.kube/config`
`-n`, `--namespace`	Namespace to check	No	all namespaces

Basic validationWith auth method checksSpecific namespace

cloudtaser-cli target validate \
  --secretstore-address https://vault.eu.example.com

cloudtaser-cli target validate \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token s.xxxx

cloudtaser-cli target validate \
  --secretstore-address https://vault.eu.example.com \
  -n production

target audit¶

Generate a data sovereignty compliance audit report. Scans all Deployments, StatefulSets, and DaemonSets in the cluster to produce a compliance audit report suitable for regulatory submissions.

System namespaces (kube-system, kube-public, kube-node-lease) are excluded.

The audit report identifies:

Protected workloads (cloudtaser-injected) with protection scores
Unprotected workloads (using K8s Secrets directly)
Orphaned Kubernetes Secrets in etcd
eBPF runtime enforcement coverage per node
Compliance readiness summary

cloudtaser-cli target audit \
  --secretstore-address https://vault.eu.example.com

Flag	Description	Required	Default
`--secretstore-address`	Secret store address for report metadata	Yes	--
`--kubeconfig`	Path to kubeconfig file	No	`~/.kube/config`
`-n`, `--namespace`	Namespace to scan	No	all namespaces
`-o`, `--output`	Output format: `text` or `json`	No	`text`

Text reportJSON for compliance toolingSpecific namespace

cloudtaser-cli target audit \
  --secretstore-address https://vault.eu.example.com

cloudtaser-cli target audit \
  --secretstore-address https://vault.eu.example.com \
  -o json > audit-report.json

cloudtaser-cli target audit \
  --secretstore-address https://vault.eu.example.com \
  -n production

target rotate¶

Trigger a rolling restart of workloads annotated with cloudtaser.io/inject: "true" to pick up new secrets from the secret store. This is equivalent to kubectl rollout restart but scoped to cloudtaser-protected workloads.

The restart is triggered by patching the pod template with a cloudtaser.io/restartedAt annotation, causing a new rollout.

cloudtaser-cli target rotate -n production

Flag	Description	Required	Default
`-n`, `--namespace`	Namespace (required)	Yes	--
`-w`, `--workload`	Specific workload to rotate (format: `kind/name`)	No	all protected workloads
`--kubeconfig`	Path to kubeconfig file	No	`~/.kube/config`
`--dry-run`	Show what would be rotated without performing the restart	No	`false`

Rotate all protected workloads in a namespaceRotate a specific workloadDry run

cloudtaser-cli target rotate -n production

cloudtaser-cli target rotate -n production -w deployment/api-server

cloudtaser-cli target rotate -n production --dry-run

target protect¶

Migrate workloads to cloudtaser sovereign secret injection. Two modes are available:

Plan-based mode (--plan): Uses a MigrationPlan YAML file generated by target discover -o. Supports interactive approval per workload (--interactive) and auto-approve for CI (--yes). This is the recommended approach for enterprise deployments.

Source-based mode (--from): Scans the cluster for resources managed by a specific secret management tool (ESO, Sealed Secrets, SOPS) and generates a migration script or executes the migration directly.

Supported --from sources:

Source	Description
`eso`	External Secrets Operator
`sealed-secrets`	Bitnami Sealed Secrets
`sops`	SOPS-encrypted K8s Secrets

# Plan-based migration (recommended)
cloudtaser-cli target protect --plan plan.yaml \
  --secretstore-address https://vault.eu.example.com --interactive

# Source-based migration
cloudtaser-cli target protect --from=eso

Flag	Description	Required	Default
`--plan`	Path to a MigrationPlan YAML file	No (requires `--from` if not set)	--
`--interactive`	Prompt for each workload (requires `--plan`)	No	`false`
`--yes`	Auto-approve all workloads (requires `--plan`, for CI)	No	`false`
`--from`	Source to migrate from: `eso`, `sealed-secrets`, `sops`	No (requires `--plan` if not set)	--
`--secretstore-address`	Secret store address (required for `--plan` or `--auto`)	No	--
`--secretstore-token`	Secret store token (required for `--auto`)	No	--
`--kubeconfig`	Path to kubeconfig file	No	`~/.kube/config`
`-n`, `--namespace`	Namespace to scan	No	all namespaces
`--auto`	Execute migration directly with `--from` (scan, read, write to the secret store, verify)	No	`false`
`--dry-run`	Show what would happen without executing	No	`false`
`--force`	Overwrite existing secrets in the secret store	No	`false`

Interactive plan migrationAuto-approve plan migration (CI)Source-based: generate ESO migration scriptSource-based: auto-migrate with dry runSource-based: auto-migrate (execute)

cloudtaser-cli target protect --plan plan.yaml \
  --secretstore-address https://vault.eu.example.com \
  --interactive

cloudtaser-cli target protect --plan plan.yaml \
  --secretstore-address https://vault.eu.example.com \
  --yes

cloudtaser-cli target protect --from=eso

cloudtaser-cli target protect --from=eso \
  --auto \
  --secretstore-address=https://vault.eu.example.com \
  --secretstore-token=hvs.xxx \
  --dry-run

cloudtaser-cli target protect --from=eso \
  --auto \
  --secretstore-address=https://vault.eu.example.com \
  --secretstore-token=hvs.xxx

Plan-based workflow is recommended

The plan-based workflow (--plan) provides a reviewable compliance artifact, supports interactive approval, and is resumable if interrupted. See Migration Plan Workflow for the full guide.

Review before executing

When using --from, the generated migration script is written to stdout. Review it carefully before executing. Use --auto --dry-run to preview auto-migration operations.

target import¶

Generate a shell script to import secrets from a cloud provider secret manager into your secret store (OpenBao or HashiCorp Vault). The imported secrets can then be consumed by workloads via cloudtaser sovereign secret injection.

Supported providers:

Provider	Description
`aws-sm`	AWS Secrets Manager
`gcp-sm`	GCP Secret Manager
`azure-kv`	Azure Key Vault

The generated script requires the appropriate cloud CLI authenticated (aws, gcloud, or az), the bao CLI installed, and jq for JSON parsing.

cloudtaser-cli target import --from=aws-sm \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token s.xxxx \
  --region eu-west-1

Flag	Description	Required	Default
`--from`	Source provider: `aws-sm`, `gcp-sm`, `azure-kv`	Yes	--
`--secretstore-address`	Destination secret store address to import into	Yes	--
`--secretstore-token`	Destination secret store token for writing secrets	Yes	--
`--prefix`	KV path prefix in the destination secret store	No	`secret/imported`
`--region`	Cloud provider region (for `aws-sm`, `gcp-sm`)	No	--
`--resource-group`	Azure resource group (for `azure-kv`)	No	--
`--vault-name`	Azure Key Vault name (for `azure-kv`)	No	--
`--dry-run`	List secrets that would be imported without importing	No	`false`

Import from AWS Secrets ManagerImport from GCP Secret ManagerImport from Azure Key VaultDry run

cloudtaser-cli target import --from=aws-sm \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token s.xxxx \
  --region eu-central-1

cloudtaser-cli target import --from=gcp-sm \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token s.xxxx

cloudtaser-cli target import --from=azure-kv \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token s.xxxx \
  --vault-name my-kv \
  --prefix secret/azure

cloudtaser-cli target import --from=gcp-sm \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token s.xxxx \
  --dry-run

target netpol¶

Generate Kubernetes NetworkPolicy YAML that restricts direct access to the secret store endpoint. Only pods with the cloudtaser.io/protected=true label are allowed to reach the secret store.

The generated policies are written to stdout as multi-document YAML. System namespaces (kube-system, kube-public, kube-node-lease) are excluded.

cloudtaser-cli target netpol \
  --secretstore-address https://vault.eu.example.com

Flag	Description	Required	Default
`--secretstore-address`	Secret store endpoint address	Yes	--
`--kubeconfig`	Path to kubeconfig file	No	`~/.kube/config`
`-n`, `--namespace`	Namespace to generate policies for	No	all namespaces
`--secretstore-port`	Secret store endpoint port	No	`8200`
`--secretstore-cidr`	CIDR for the secret store endpoint (if not provided, hostname is resolved)	No	--

Generate and reviewGenerate and applyCustom secret store CIDR and port

cloudtaser-cli target netpol \
  --secretstore-address https://vault.eu.example.com > netpol.yaml

cloudtaser-cli target netpol \
  --secretstore-address https://vault.eu.example.com | kubectl apply -f -

cloudtaser-cli target netpol \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-cidr 10.0.1.50/32 \
  --secretstore-port 443

demo¶

Generate an end-to-end cloudtaser sovereignty demo script. The script is designed for asciinema recording and live presentations.

The demo walks through seven steps:

Deploy an unprotected sample app with a K8s Secret
Show the problem -- secret visible in /proc/1/environ
Store the secret in an EU-hosted secret store (OpenBao in the demo; HashiCorp Vault works identically)
Annotate the deployment to enable cloudtaser injection
Verify secret is in memory only -- not in K8s Secrets or /proc
Attempt /proc/PID/mem read -- blocked by eBPF enforcement
Show the protection score from the wrapper health endpoint

The generated script is written to stdout.

cloudtaser-cli demo

Flag	Description	Required	Default
`--namespace`	Kubernetes namespace for the demo	No	`cloudtaser-demo`
`--secretstore-address`	Secret store address	No	`https://openbao.openbao.svc:8200`
`--cleanup`	Include cleanup steps at the end	No	`false`
`--pause`	Add pauses between steps for live presentations	No	`false`

Generate demo scriptWith pauses for live presentationWith cleanup and custom namespaceSave for asciinema recording

cloudtaser demo

cloudtaser demo --pause

cloudtaser demo --namespace=my-demo --cleanup

cloudtaser demo --pause > demo.sh && chmod +x demo.sh

target install¶

Generate a setup script for the cloudtaser operator deployment. Deploys the operator, mutating webhook, and optional eBPF/proxy components into a Kubernetes cluster via Helm.

The operator provides:

Mutating admission webhook for automatic wrapper injection
CloudTaserConfig CRD for per-workload secret configuration
Optional eBPF daemonset for runtime enforcement
Optional S3/DB proxy injection for data-at-rest encryption

The generated script is written to stdout.

cloudtaser-cli target install \
  --secretstore-address=https://openbao.openbao.svc:8200

Flag	Description	Required	Default
`--secretstore-address`	Secret store address (e.g. OpenBao / HashiCorp Vault)	Yes	--
`--secretstore-auth-method`	Secret store auth method	No	`kubernetes`
`--secretstore-auth-path`	Secret store auth mount path	No	`kubernetes`
`--namespace`	Kubernetes namespace for the operator	No	`cloudtaser`
`--chart-version`	Helm chart version	No	`latest`
`--enable-ebpf`	Enable eBPF daemonset	No	`true`
`--enable-s3-proxy`	Enable S3 proxy injection support	No	`false`
`--enable-db-proxy`	Enable DB proxy injection support	No	`false`

Basic operator setupWith custom namespace and chart versionWith all optional componentsSave to file

cloudtaser-cli target install \
  --secretstore-address=https://openbao.openbao.svc:8200

cloudtaser-cli target install \
  --secretstore-address=https://vault.eu.example.com \
  --namespace=cloudtaser-system \
  --chart-version=0.1.0

cloudtaser-cli target install \
  --secretstore-address=https://openbao.openbao.svc:8200 \
  --enable-s3-proxy \
  --enable-db-proxy

cloudtaser-cli target install \
  --secretstore-address=https://openbao.openbao.svc:8200 > setup-operator.sh

source install --method¶

Generate a setup script for OpenBao sovereign secret storage. Two deployment methods are supported:

Method	Description
`kubernetes`	Deploys OpenBao via Helm into a Kubernetes cluster with HA Raft storage, audit logging, KV v2 engine, and Kubernetes auth method pre-configured
`linux`	Installs OpenBao as a systemd service on a Linux host with Raft storage, audit logging, and a production-ready config

The generated script is written to stdout.

cloudtaser-cli source install --method=kubernetes

Flag	Description	Required	Default
`--method`	Deployment method: `kubernetes` or `linux`	Yes	--
`--namespace`	Kubernetes namespace for OpenBao (`kubernetes` method)	No	`openbao`
`--secretstore-address`	Listen address (`linux` method) or service URL (`kubernetes` method)	No	`0.0.0.0:8200` (linux)
`--kv-path`	KV v2 engine mount path	No	`secret`
`--auth-path`	Kubernetes auth method mount path	No	`kubernetes`
`--no-tls`	Disable TLS in generated config (development only, `linux` method)	No	`false`
`--tls-cert-file`	Path to TLS certificate file (`linux` method)	No	`/etc/openbao/tls/server.crt`
`--tls-key-file`	Path to TLS private key file (`linux` method)	No	`/etc/openbao/tls/server.key`
`--tls-client-ca-file`	Path to client CA certificate for mutual TLS (`linux` method)	No	--

Kubernetes setupKubernetes with custom namespaceLinux setupSave to file

cloudtaser-cli source install --method=kubernetes

cloudtaser-cli source install --method=kubernetes --namespace=vault

cloudtaser-cli source install --method=linux --secretstore-address=0.0.0.0:8200

cloudtaser-cli source install --method=kubernetes > setup-vault.sh

source install --type=system¶

Generate a setup script that configures a systemd service to use cloudtaser for sovereign secret injection. Wraps the existing service with the cloudtaser wrapper (which fetches secrets from the secret store directly into process memory) and deploys the eBPF agent for runtime enforcement.

The generated script is written to stdout.

cloudtaser-cli source install --type=system \
  --service=myapp \
  --secretstore-address=https://vault.eu.example.com \
  --secretstore-role=myapp \
  --secrets=secret/data/myapp/db,secret/data/myapp/api

Flag	Description	Required	Default
`--service`	systemd service name to protect	Yes	--
`--secretstore-address`	Secret store address (e.g. OpenBao / HashiCorp Vault)	Yes	--
`--secretstore-role`	Secret store role for authentication	Yes	--
`--secrets`	Comma-separated secret paths in the secret store	Yes	--
`--wrapper-version`	cloudtaser-wrapper binary version	No	`latest`
`--ebpf-version`	cloudtaser-ebpf agent binary version	No	`latest`

Basic systemd setupWith specific versions

cloudtaser-cli source install --type=system \
  --service=myapp \
  --secretstore-address=https://vault.eu.example.com \
  --secretstore-role=myapp \
  --secrets=secret/data/myapp/db,secret/data/myapp/api

cloudtaser-cli source install --type=system \
  --service=myapp \
  --secretstore-address=https://vault.eu.example.com \
  --secretstore-role=myapp \
  --secrets=secret/data/myapp/db \
  --wrapper-version=v0.1.0 \
  --ebpf-version=v0.1.0 > setup-myapp.sh

source install¶

Install and bootstrap a secret store (OpenBao (also compatible with HashiCorp Vault)) for cloudtaser. Both backends expose identical APIs, so the same bootstrap sequence works for either.

The install command handles the infrastructure bootstrap:

Wait for secret store pod-0 to be reachable
Initialize with Shamir secret sharing
Unseal pod-0 with threshold keys
Join and unseal pod-1 and pod-2 (HA replicas)
Store init output (unseal keys + root token) in a Kubernetes Secret

After install, run source configure to set up policies, roles, and auth.

cloudtaser-cli source install \
  --openbao-addr https://openbao.vault.svc:8200 \
  --namespace vault \
  --release-name openbao

Flag	Description	Required	Default
`--type`	Install type: `k8s` (Kubernetes) or `system` (systemd)	No	`k8s`
`--backend`	Secret store backend: `openbao` or `vault`	No	`openbao`
`--openbao-addr`	Secret store service URL	No	env `OPENBAO_ADDR`
`--namespace`	K8s namespace where secret store is deployed	No	env `OPENBAO_NAMESPACE`
`--release-name`	Helm release name for per-pod DNS	No	env `OPENBAO_RELEASE_NAME`
`--kubeconfig`	Path to kubeconfig file	No	`~/.kube/config`
`--shamir-shares`	Number of Shamir shares	No	`5`
`--shamir-threshold`	Unseal threshold	No	`3`
`--output-secret`	K8s secret name for init output	No	`cloudtaser-openbao-init`
`--image`	Custom container image override	No	--
`--tag`	Custom image tag override	No	--
`--method`	Deployment method: `kubernetes` or `linux` (generates setup script)	No	--

Install with flags (OpenBao)Install with environment variablesInstall with HashiCorp Vault

cloudtaser-cli source install \
  --openbao-addr https://openbao.vault.svc:8200 \
  --namespace vault \
  --release-name openbao

export OPENBAO_ADDR=https://openbao.vault.svc:8200
export OPENBAO_NAMESPACE=vault
export OPENBAO_RELEASE_NAME=openbao
cloudtaser-cli source install

cloudtaser-cli source install \
  --backend vault \
  --openbao-addr https://vault.vault.svc:8200 \
  --namespace vault \
  --release-name vault

source configure¶

Configure policies, roles, and authentication methods on a previously initialized secret store.

This command:

Enable stdout audit logging
Enable KV v2 secret engine
Configure Kubernetes auth method
Create cloudtaser wrapper policy (read access to KV secrets)
Create cloudtaser wrapper role for service account authentication
Create cloudtaser operator policy (manage operational secrets)
Create cloudtaser operator role for operator authentication

Requires a root token or a token with sufficient privileges.

cloudtaser-cli source configure \
  --openbao-addr https://openbao.vault.svc:8200 \
  --token hvs.EXAMPLE

Flag	Description	Required	Default
`--token`	Root token or token with admin privileges	Yes	--
`--openbao-addr`	Secret store service URL	No	env `OPENBAO_ADDR`
`--namespace`	K8s namespace where secret store is deployed	No	env `OPENBAO_NAMESPACE`
`--backend`	Secret store backend: `openbao` or `vault`	No	`openbao`
`--kv-path`	KV v2 mount path	No	`secret`
`--auth-path`	Kubernetes auth mount path	No	`kubernetes`
`--policy-name`	Policy name	No	`cloudtaser`
`--role-name`	Role name	No	`cloudtaser`
`--bound-sa-names`	Bound service account names	No	`*`
`--bound-sa-namespaces`	Bound service account namespaces	No	`*`
`--role-ttl`	Role token TTL	No	`1h`

All flags can also be set via environment variables. Flags take precedence over environment variables when both are set.

Environment Variable	Description
`OPENBAO_ADDR`	Secret store service URL
`OPENBAO_NAMESPACE`	K8s namespace where secret store is deployed
`OPENBAO_RELEASE_NAME`	Helm release name (for per-pod DNS)
`BOOTSTRAP_KV_PATH`	KV v2 mount path
`BOOTSTRAP_AUTH_PATH`	Kubernetes auth mount path
`BOOTSTRAP_POLICY_NAME`	Policy name
`BOOTSTRAP_ROLE_NAME`	Role name
`BOOTSTRAP_ROLE_BOUND_SA_NAMES`	Bound service account names
`BOOTSTRAP_ROLE_BOUND_SA_NAMESPACES`	Bound service account namespaces
`BOOTSTRAP_ROLE_TTL`	Role token TTL

Configure with root tokenConfigure with custom policy/roleDry run

cloudtaser-cli source configure \
  --openbao-addr https://openbao.vault.svc:8200 \
  --token hvs.EXAMPLE

cloudtaser-cli source configure \
  --openbao-addr https://openbao.vault.svc:8200 \
  --token hvs.EXAMPLE \
  --policy-name my-policy \
  --role-name my-role

cloudtaser-cli source configure \
  --openbao-addr https://openbao.vault.svc:8200 \
  --token hvs.EXAMPLE \
  --dry-run

source apply-plan¶

Apply a migration plan to OpenBao source. Reads a MigrationPlan YAML file and provisions OpenBao with the policies and Kubernetes auth roles required for each tenant.

For each tenant in the plan:

Ensures the KV v2 secrets engine is mounted
Creates an OpenBao policy <tenant-name>-read with read access to the tenant's secret paths
Creates a Kubernetes auth role <tenant-name>-role bound to the tenant's namespace

This command does NOT write secret values -- populating the actual secret data in OpenBao is the user's responsibility.

cloudtaser-cli source apply-plan plan.yaml \
  --openbao-addr https://vault.eu.example.com \
  --token hvs.ADMIN_TOKEN

Flag	Description	Required	Default
`--openbao-addr`	OpenBao address	Yes	--
`--token`	OpenBao token with admin privileges	Yes	--
`--dry-run`	Print what would be created without making changes	No	`false`
`--auth-path`	Kubernetes auth mount path	No	`kubernetes`
`--kv-mount`	KV v2 mount path	No	`secret`

Apply planDry run

cloudtaser-cli source apply-plan plan.yaml \
  --openbao-addr https://vault.eu.example.com \
  --token hvs.ADMIN_TOKEN

cloudtaser-cli source apply-plan plan.yaml \
  --openbao-addr https://vault.eu.example.com \
  --token hvs.ADMIN_TOKEN \
  --dry-run

See Migration Plan Workflow for the full step-by-step guide.

source verify-plan¶

Verify that all secrets in a migration plan exist in OpenBao. Reads a MigrationPlan YAML file and checks each secret mapping against OpenBao source.

For each secret mapping the command checks:

OpenBao path exists
The path has data (values populated)
The fields listed in the mapping exist in OpenBao data

This is a read-only operation. Use it after populating secret values to confirm everything is ready before running target protect --plan.

cloudtaser-cli source verify-plan plan.yaml \
  --openbao-addr https://vault.eu.example.com \
  --token hvs.ADMIN_TOKEN

Flag	Description	Required	Default
`--openbao-addr`	OpenBao address	Yes	--
`--token`	OpenBao token	Yes	--

Verify plan

cloudtaser-cli source verify-plan plan.yaml \
  --openbao-addr https://vault.eu.example.com \
  --token hvs.ADMIN_TOKEN

The command exits with a non-zero status if any secrets are not ready, making it suitable for CI/CD gates.

See Migration Plan Workflow for the full step-by-step guide and Plan File Format for the YAML schema.

source status¶

Check secret store connectivity and health.

cloudtaser-cli source status \
  --secretstore-address https://vault.eu.example.com

Flag	Description	Required	Default
`--secretstore-address`	Secret store address (e.g. OpenBao / HashiCorp Vault)	Yes	--
`--secretstore-token`	Secret store token (optional, enables detailed checks)	No	--

Basic health checkWith detailed auth/engine info

cloudtaser-cli source status \
  --secretstore-address https://vault.eu.example.com

cloudtaser-cli source status \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token hvs.EXAMPLE