CLI Reference¶

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

Installation¶

macOS (Homebrew)Linux (binary)Container

brew install skipopsltd/tap/cloudtaser

curl -sL https://github.com/skipopsltd/cloudtaser-cli/releases/latest/download/cloudtaser-linux-amd64 \
  -o /usr/local/bin/cloudtaser && chmod +x /usr/local/bin/cloudtaser

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

Global Flags¶

These flags are available on all commands:

Flag	Description	Default
`--kubeconfig`	Path to kubeconfig file	`~/.kube/config`
`-n`, `--namespace`	Target namespace (use `--all-namespaces` for cluster-wide)	`default`
`--all-namespaces`	Operate across all namespaces	`false`
`-o`, `--output`	Output format: `text`, `json`, `yaml`	`text`
`--vault-address`	Vault/OpenBao endpoint URL	--
`--vault-token`	Vault token (for admin operations)	--
`--vault-role`	Vault Kubernetes auth role name	`cloudtaser`
`-v`, `--verbose`	Enable verbose output	`false`

Commands¶

connect¶

Configure Vault Kubernetes auth for a cluster. Creates a ServiceAccount for vault token review, enables and configures the Kubernetes auth backend in vault, and creates a vault role for pod authentication.

cloudtaser connect \
  --vault-address https://vault.eu.example.com \
  --vault-token hvs.YOUR_ADMIN_TOKEN \
  --namespaces default,production \
  --secret-paths "secret/data/*"

Flag	Description	Required
`--vault-address`	Vault endpoint URL	Yes
`--vault-token`	Vault admin token (needs `sys/auth/`, `auth/kubernetes/`, `sys/policies/*`)	Yes
`--namespaces`	Comma-separated list of namespaces to allow	No (defaults to all)
`--secret-paths`	Vault paths the role is allowed to access	No
`--vault-role`	Name of the Kubernetes auth role to create	No (default: `cloudtaser`)
`--dry-run`	Preview changes without applying	No

discover¶

Scan the cluster for workloads that reference Kubernetes Secrets. Outputs SecretMapping CRD YAML to stdout, identifying candidates for CloudTaser migration.

cloudtaser discover \
  --vault-address https://vault.eu.example.com \
  --vault-role cloudtaser

Scans Deployments, StatefulSets, and DaemonSets for secretKeyRef, secretRef, envFrom with secret references, and Vault injector annotations.

Flag	Description	Required
`--vault-address`	Vault endpoint URL	Yes
`--vault-role`	Vault auth role name	No (default: `cloudtaser`)
`-n`, `--namespace`	Namespace to scan	No (defaults to all)

Discover and applyPreview to file

cloudtaser discover \
  --vault-address https://vault.eu.example.com | kubectl apply -f -

cloudtaser discover \
  --vault-address https://vault.eu.example.com > mappings.yaml

migrate¶

Generate migration scripts from existing secret management tools to CloudTaser. Supports External Secrets Operator, Sealed Secrets, and SOPS.

cloudtaser migrate --from=eso \
  --vault-address https://vault.eu.example.com \
  --vault-role cloudtaser

Flag	Description	Required
`--from`	Source tool: `eso`, `sealed-secrets`, `sops`	Yes
`--vault-address`	Vault endpoint URL	Yes
`--vault-role`	Vault auth role name	No (default: `cloudtaser`)
`--vault-path-prefix`	Override vault path prefix	No
`-n`, `--namespace`	Namespace to scan	No (defaults to all)
`--dry-run`	Preview without generating script	No
`-o`	Output file path for the migration script	No (stdout)

Vault must contain the secrets

The migration script assumes secrets are already present in vault at the expected paths. For Sealed Secrets and SOPS, you must import secrets into vault first. See the Migration Guide.

setup vault¶

Configure an OpenBao or Vault instance for use with CloudTaser. Enables the KV v2 secrets engine, Transit engine (for S3 proxy), and creates policies.

cloudtaser setup vault \
  --vault-address https://vault.eu.example.com \
  --vault-token hvs.YOUR_ADMIN_TOKEN

Flag	Description	Required
`--vault-address`	Vault endpoint URL	Yes
`--vault-token`	Vault admin token	Yes
`--enable-transit`	Enable Transit engine for S3 proxy envelope encryption	No (default: `false`)
`--transit-key`	Transit key name	No (default: `cloudtaser`)
`--dry-run`	Preview changes without applying	No

setup systemd¶

Configure systemd services to use CloudTaser for secret injection on non-Kubernetes hosts. Generates systemd unit drop-ins that invoke the wrapper binary before the service starts.

cloudtaser setup systemd \
  --service myapp.service \
  --vault-address https://vault.eu.example.com \
  --vault-role myhost \
  --secret-paths "secret/data/prod/myapp" \
  --env-map "db_password=PGPASSWORD"

Flag	Description	Required
`--service`	systemd service name	Yes
`--vault-address`	Vault endpoint URL	Yes
`--vault-role`	Vault auth role name	Yes
`--secret-paths`	Vault KV v2 paths	Yes
`--env-map`	Vault field to env var mappings	Yes
`--wrapper-path`	Path to the wrapper binary on the host	No (default: `/usr/local/bin/cloudtaser-wrapper`)
`--dry-run`	Preview the generated drop-in without installing	No

import¶

Import secrets from cloud provider secret managers into your EU-hosted vault. Supports AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault.

cloudtaser import --from=aws-sm \
  --vault-address https://vault.eu.example.com \
  --vault-token hvs.YOUR_ADMIN_TOKEN \
  --prefix secret/data/prod

Flag	Description	Required
`--from`	Source provider: `aws-sm`, `gcp-sm`, `azure-kv`	Yes
`--vault-address`	Vault endpoint URL	Yes
`--vault-token`	Vault admin token	Yes
`--prefix`	Vault path prefix for imported secrets	No (default: `secret/data`)
`--filter`	Regex filter for secret names	No
`--region`	Cloud provider region	No (uses SDK default)
`--dry-run`	List secrets that would be imported without writing	No

Import from AWS Secrets ManagerImport from GCP Secret ManagerImport from Azure Key Vault

cloudtaser import --from=aws-sm \
  --vault-address https://vault.eu.example.com \
  --vault-token hvs.YOUR_ADMIN_TOKEN \
  --prefix secret/data/prod \
  --region eu-central-1

cloudtaser import --from=gcp-sm \
  --vault-address https://vault.eu.example.com \
  --vault-token hvs.YOUR_ADMIN_TOKEN \
  --prefix secret/data/prod

cloudtaser import --from=azure-kv \
  --vault-address https://vault.eu.example.com \
  --vault-token hvs.YOUR_ADMIN_TOKEN \
  --prefix secret/data/prod

validate¶

Validate the CloudTaser deployment and vault connectivity. Checks all components and reports issues.

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

Flag	Description	Required
`--vault-address`	Vault endpoint URL	Yes
`--vault-token`	Vault token (enables deeper auth validation)	No

Validation checks:

Kubernetes cluster connectivity
CloudTaser operator deployment and readiness
Mutating webhook configuration and CA bundle
Vault health and seal status
Kubernetes auth method configuration in vault
eBPF daemonset status and node coverage
Protected and unprotected workload counts

status¶

Show the current status of CloudTaser components and protected workloads.

cloudtaser status

Flag	Description	Required
`-n`, `--namespace`	Namespace to check	No (defaults to all)
`-o`, `--output`	Output format: `text`, `json`	No (default: `text`)

Reports:

Operator health and version
Webhook configuration status
eBPF daemonset coverage (nodes running vs total)
Protected workload count per namespace
Per-workload protection scores

audit¶

Generate a data sovereignty compliance audit report. Scans all workloads and produces a report suitable for regulatory submissions.

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

Flag	Description	Required
`--vault-address`	Vault endpoint URL	Yes
`-n`, `--namespace`	Namespace to audit	No (defaults to all)
`-o`, `--output`	Output format: `text`, `json`	No (default: `text`)

The audit report includes:

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

Text reportJSON for compliance tooling

cloudtaser audit --vault-address https://vault.eu.example.com

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

netpol¶

Generate Kubernetes NetworkPolicies that restrict pod network access to only the vault endpoint. Limits the blast radius of a compromised pod by preventing it from reaching any other external service.

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

Flag	Description	Required
`--vault-address`	Vault endpoint URL (used to derive allowed egress CIDR)	Yes
`-n`, `--namespace`	Namespace to generate policies for	No (defaults to all)
`--apply`	Apply the generated policies directly	No (default: output to stdout)

Generate and reviewGenerate and apply

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

cloudtaser netpol \
  --vault-address https://vault.eu.example.com \
  --apply

rotate¶

Trigger a rolling restart of CloudTaser-protected workloads. Useful after a vault secret rotation to force all pods to re-fetch secrets.

cloudtaser rotate

Flag	Description	Required
`-n`, `--namespace`	Namespace to rotate	No (defaults to all CloudTaser-injected workloads)
`--deployment`	Specific deployment name to rotate	No
`--dry-run`	Preview which workloads would be restarted	No

Rotate all workloads in a namespaceRotate a specific deploymentDry run

cloudtaser rotate -n production

cloudtaser rotate -n production --deployment myapp

cloudtaser rotate -n production --dry-run

Rotation strategies

The rotate command triggers a Kubernetes rolling restart. For in-place secret rotation without pod restart, configure the cloudtaser.io/rotation: "sighup" annotation on workloads that support config reload via SIGHUP.