CLI Reference¶

Identity and store-login boundary

Direct Kubernetes-auth store login authenticates a ServiceAccount and namespace, not the injected wrapper or Deployment. A pod creator using that identity, or node root stealing its JWT, can log in separately and read the role's allowed records. Use one workload per identity, exact-record policies and restricted workload creation. Exec/memory controls do not block that raw login. This limit remains unresolved; see the Security Model. One workload per identity applies on both direct and Port paths. Denial of a second same-identity workload on Port has not been established.

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.

Documented cohort CLI: v0.19.176

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 download

brew tap cloudtaser/tap https://codeberg.org/cloudtaser/homebrew-tap
brew install cloudtaser/tap/cloudtaser

The formula installs the newest cloudtaser-cli release, which may select a different chart and component set from this documentation. For the documented cohort, use Direct download below with v0.19.176.

These URLs select the documented cohort CLI v0.19.176. Verify its signed checksums before executing the binary; see Supply-Chain Evidence.

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

# macOS (Apple Silicon; arm64 unverified)
curl -sL https://releases.cloudtaser.io/cli/v0.19.176/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.19.176/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.19.176/cloudtaser-cli-linux-amd64 \
  -o /usr/local/bin/cloudtaser-cli && chmod +x /usr/local/bin/cloudtaser-cli

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

Published binary targets: darwin-amd64, darwin-arm64, linux-amd64, linux-arm64. Arm64 is unverified; a published binary or image does not establish a verified deployment.

Installer release track

install.sh also installs the newest CLI through cli/latest; it does not select the documented CLI v0.19.176. Its optional --demo bootstrap pins OpenBao chart 0.2.0, while this documentation's cohort selects 0.2.17. For a matched deployment, use the versioned direct download above and the cohort installation procedure.

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:8200) 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 annotation and environment compatibility). 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 these steps:

Reads the target API endpoint and CA from the kubeconfig
In --mode direct, creates the token reviewer: ServiceAccount cloudtaser-system/cloudtaser-token-reviewer with a ClusterRole that may only create TokenReviews, and a bounded token for it. Before the secret store is changed, the CLI proves with the API server that this token can review a workload token for the cloudtaser.io/secret-fetch audience. No Kubernetes Secret is created; the token goes only to the secret store's auth configuration
Enables and configures the Kubernetes auth backend in the secret store
Creates a secret-store role (and optionally a policy) for pod authentication
Stores the cluster fingerprint that the operator verifies

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 --mode direct \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token-file /etc/cloudtaser/admin.token

Why direct mode needs a reviewer

Workload tokens are issued for the cloudtaser.io/secret-fetch audience only, so they cannot authenticate to the Kubernetes API as a TokenReview caller. Without a reviewer, every direct-mode login fails with 403. The reviewer token expires after --token-reviewer-ttl (90 days by default); target connect prints the expiry and target status shows the days left, warning under 14 days. An API server that caps tokens below 24 hours is refused.

Renew the token by running target connect --mode direct on a schedule from wherever the secret store admin token lives, outside the cluster. CloudTaser deliberately does not renew it from inside the cluster: an identity allowed to rewrite the auth configuration could also repoint it to another cluster. To revoke every issued reviewer token, delete or recreate the cloudtaser-system/cloudtaser-token-reviewer ServiceAccount.

An OpenBao that runs inside the target cluster needs no reviewer: configure its Kubernetes auth with kubernetes_host=https://kubernetes.default.svc and its own ServiceAccount token (that ServiceAccount needs system:auth-delegator). source install --existing-vault configures the same reviewer (with the same --token-reviewer-ttl and renewal by rerunning it) and makes its wrapper role require the cloudtaser.io/secret-fetch audience.

Cluster fingerprint endpoint

The fingerprint records the in-cluster API endpoint (the kubernetes Service in the default namespace), which is what the operator sees, not your kubeconfig address or --kube-endpoint. --kube-endpoint only sets the address the secret store uses for TokenReview.

Flag	Description	Required	Default
`--secretstore-address`	Secret store address (e.g. OpenBao / HashiCorp Vault)	Yes	--
`--secretstore-token-file`	File holding a secret store token with admin privileges (or `SECRETSTORE_TOKEN`)	Yes	--
`--mode`	`p2p`, `reverse` or `direct`	No	`p2p`
`--kube-endpoint`	K8s API endpoint the secret store uses for TokenReview	No	from kubeconfig
`--auth-path`	Secret store auth method mount path	No	`kubernetes`
`--token-reviewer-ttl`	Direct mode: lifetime of the token reviewer token (minimum `24h`)	No	`2160h` (90 days)
`--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-file /etc/cloudtaser/admin.token \
  --namespaces default,myapp \
  --secret-paths "secret/data/*"

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

cloudtaser-cli target connect \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token-file /etc/cloudtaser/admin.token \
  --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 secretstore.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.

The Fingerprint line shows whether the operator has latched a cluster-identity mismatch. A latched operator denies every protected pod even though the operator, webhook and eBPF agent report healthy; the line names the mismatching fields and the recovery command. The state is read from the operator's logs. When they cannot be read, or no longer reach back to the verifier's start line (after log rotation), it shows Unknown rather than Verified; if protected pods are denied, use target fingerprint clear-latch --restart.

In direct mode, the Token reviewer line shows how many days the secret store's reviewer token has left.

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 fingerprint clear-latch¶

Recover an operator that has latched a cluster-fingerprint mismatch. The operator keeps the latch until it restarts, and a later matching check does not clear it.

The command compares the fingerprint stored in the secret store with the live cluster. It restarts the operator only when they match, so each new operator pod checks the same record again and latches again on a real mismatch. When only the stored API endpoint or serving certificate differs, for example a record written by an older CLI with the kubeconfig address, --re-register replaces the record first. It refuses when the kube-system UID or the cluster CA differs, because that is the repointing the check protects against.

cloudtaser-cli target fingerprint clear-latch --re-register \
  --secretstore-address https://vault.eu.example.com \
  --secretstore-token-file /etc/cloudtaser/admin.token

Flag	Description	Required	Default
`--secretstore-address`	Secret store address	Yes	--
`--secretstore-token-file`	File holding the secret store token (or `SECRETSTORE_TOKEN`)	Yes	--
`--re-register`	Replace a stored record whose endpoint or serving certificate differs, when the kube-system UID and CA match	No	`false`
`--restart`	Restart the operator once the record matches, even when its logs no longer show the latch	No	`false`
`--fingerprint`	Cluster ID the record is stored under	No	kube-system UID
`-n`, `--namespace`	Operator namespace	No	`cloudtaser-system`

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 secretstore.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:

Not yet verified; do not use for production

Signed release compatibility and live application cutover for the plan checks below are not yet verified. Earlier CLIs could print migrated after patching while old unprotected Pods kept using Kubernetes Secrets. Source existence, a patch or an old Available replica cannot prove cutover.

Plan-based mode (--plan): Uses a v2 MigrationPlan YAML file generated by target discover -o. The candidate supports interactive approval per workload (--interactive) and auto-approve for CI (--yes). Its source/tests require a complete new owned injected rollout with readiness probes, Ready/started running affected containers and zero restarts before reporting migrated. It removes exact mapped secretKeyRef inputs, uses explicit matching roles and wrapper-compatible field mappings, revalidates older status markers and reports retained source Secrets. Application Service verification and retirement remain explicit owner steps. Failure can leave a changed template pending and does not automatically roll back. See the candidate migration procedure.

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`
`--rollout-timeout`	Plan workload verification deadline	No	`5m`
`--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¶

demo groups the demo commands. demo generate writes a script to stdout; demo run executes steps and demo serve runs the demo session service. These demo services are not a customer installation procedure.

cloudtaser-cli demo generate --pause > demo.sh

target install¶

Installs the operator into the selected cluster. Use --dry-run to render YAML to stdout without applying it.

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 default action applies to the cluster; --dry-run renders YAML to stdout.

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

Flag	Description	Required	Default
`--mode`	`deploy` (chart only), `p2p` or `direct`	No	`deploy`
`--secretstore-address`	Secret store address (e.g. OpenBao / HashiCorp Vault)	Yes (`direct`)	--
`--secretstore-auth-method`	Secret store auth method	No	`kubernetes`
`--secretstore-auth-path`	Secret store auth mount name, as passed to `target connect --auth-path`. The operator is configured with `auth/<name>`	No	`kubernetes`
`--namespace`	Kubernetes namespace for the operator	No	`cloudtaser`
`--chart-version`	Reviewed chart version. The archive and its signature are verified against the CloudTaser release key before install; an override must be a signed chart at or above 1.0.266	No	reviewed pin of the CLI release (`1.0.301` in CLI v0.19.148)
`--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`
`--enable-volume-shield`	Enable Volume Shield. Broker and sidecar use the verified wrapper pin, digest-pinned from its signed `release.json`; an explicit `volumeShield.*.image.tag` must be a signed wrapper release at or above v0.2.180 (v0.2.182 for the broker on chart 1.0.299 and later)	No	`false`

Direct mode. --mode direct selects the direct profile: the vault secret backend, reverse-connect and the beacon off, and an operator NetworkPolicy rule that allows egress to the secret store on the port of --secretstore-address. The CLI derives that rule from an IP-literal address. For a hostname it stops with exit code 4 (usage error) before contacting the cluster, because DNS seen by the CLI is not the cluster's: pass --set networkPolicy.vaultCIDR=<CIDR> with the addresses the store resolves to inside the cluster. That CIDR covers only the operator pod: when the operator manages per-namespace NetworkPolicies for wrapped pods, it derives their egress to the store from the address itself and only for an IP literal, so with a hostname those pods need their own egress rule.

Only --set overrides the backend and reverse-connect choice of --mode direct; a values file (-f) cannot turn it back into P2P. The egress values (networkPolicy.vaultCIDR, networkPolicy.vaultPort and their secretstore* names) can come from --set or -f.

cloudtaser-cli target install --mode direct \
  --secretstore-address=https://openbao.openbao.svc:8200 \
  --set networkPolicy.vaultCIDR=10.42.0.0/16

Basic operator setupWith custom namespace and chart versionWith all optional componentsRender without applying

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=1.0.359

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

cloudtaser-cli target install --dry-run \
  --secretstore-address=https://openbao.openbao.svc:8200 > operator.yaml

Source installation types¶

The published command uses --type for Linux, systemd and Docker installation. Use the generated command metadata below for its flag names. The general source install --type=k8s route is refused; source install bao is a separate chart command and does not qualify a Kubernetes Port deployment. Follow the host-Port procedure for the supported customer path.

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 release. An override must be a signed release at or above v0.2.180	No	reviewed pin of the CLI release (`v0.2.182` in CLI v0.19.148)
`--ebpf-version`	cloudtaser-ebpf agent release. An override must be a signed release at or above v0.13.122	No	reviewed pin of the CLI release (`v0.13.130` in CLI v0.19.148)

The CLI never resolves a mutable latest release. Before writing the script, it verifies each selected release's signed SHA256SUMS against the CloudTaser release key. The script downloads the binaries from https://releases.cloudtaser.io and refuses to install any binary whose SHA-256 differs from the verified value. Generating the script needs HTTPS access to releases.cloudtaser.io.

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.2.182 \
  --ebpf-version=v0.13.130 > 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¶

Not yet verified; do not use for production

These plan examples accompany the migration candidate. Its final role-writer compatibility and live cutover are not yet verified; do not substitute this direct-store workflow for managed Port/beacon authority provisioning.

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 \
  --secretstore-address https://vault.eu.example.com \
  --ca-cert ./source-ca.pem \
  --secretstore-token-file ./private-bootstrap.token

Flag	Description	Required	Default
`--secretstore-address`	OpenBao address	Yes	--
`--secretstore-token-file`	Private token file or `-` for stdin	Yes	--
`--ca-cert`, `--secretstore-ca-file`	Verified source CA PEM	No	--
`--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 \
  --secretstore-address https://vault.eu.example.com \
  --ca-cert ./source-ca.pem \
  --secretstore-token-file ./private-bootstrap.token

cloudtaser-cli source apply-plan plan.yaml \
  --secretstore-address https://vault.eu.example.com \
  --ca-cert ./source-ca.pem \
  --secretstore-token-file ./private-bootstrap.token \
  --dry-run

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

source verify-plan¶

Source verification checks stored paths/fields, not application delivery or removal of Kubernetes Secret references. Live cutover is not yet verified for the migration candidate documented here.

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 check source readiness before running target protect --plan; the replacement application and its Service still need separate verification.

cloudtaser-cli source verify-plan plan.yaml \
  --secretstore-address https://vault.eu.example.com \
  --ca-cert ./source-ca.pem \
  --secretstore-token-file ./private-bootstrap.token

Flag	Description	Required	Default
`--secretstore-address`	OpenBao address	Yes	--
`--secretstore-token-file`	Private token file or `-` for stdin	Yes	--
`--ca-cert`, `--secretstore-ca-file`	Verified source CA PEM	No	--

Verify plan

cloudtaser-cli source verify-plan plan.yaml \
  --secretstore-address https://vault.eu.example.com \
  --ca-cert ./source-ca.pem \
  --secretstore-token-file ./private-bootstrap.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

Published command reference¶

See the command reference for the published CLI v0.19.176 command tree, visible flags and effective registration defaults. See Supported Paths for deployment qualification.