Getting Started with CloudTaser on GKE¶

This guide walks you through deploying CloudTaser on a GKE cluster and protecting your first workload. By the end, your application secrets will be fetched directly from an EU-hosted vault into process memory, bypassing Kubernetes Secrets and etcd entirely.

Prerequisites¶

Before you begin

Ensure you have the following tools installed and configured:

A GKE Standard cluster (1.24+) with kubectl access
gcloud CLI authenticated with your project
helm v3.x installed
cloudtaser CLI installed (CLI Reference)
An EU-hosted OpenBao or HashiCorp Vault instance (or deploy one in Step 1)

Step 1: Deploy OpenBao in an EU Region¶

CloudTaser requires a vault instance hosted in the EU. This is fundamental to the sovereignty guarantee: secrets never leave EU jurisdiction.

Jurisdiction matters

The vault instance must run in an EU region. Deploying outside the EU undermines the entire sovereignty model. Choose a region such as europe-west1 (Belgium), europe-west3 (Frankfurt), or europe-west4 (Netherlands).

Deploy OpenBao on a VM or Kubernetes cluster in an EU region:

# Deploy OpenBao on a GCE VM in Belgium
gcloud compute instances create openbao-eu \
  --zone=europe-west1-b \
  --machine-type=e2-medium \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud

After installation, initialize and unseal OpenBao:

# Initialize
openbao operator init -key-shares=5 -key-threshold=3

# Unseal (repeat with 3 different keys)
openbao operator unseal <key1>
openbao operator unseal <key2>
openbao operator unseal <key3>

# Enable KV v2 secrets engine
openbao secrets enable -path=secret kv-v2

# Store a test secret
openbao kv put secret/myapp/config \
  db_password="s3cret" \
  api_key="ak-12345"

Tip

Ensure the vault instance is reachable from your GKE cluster via firewall rules, VPN, or a public endpoint with TLS.

Step 2: Install CloudTaser via Helm¶

Add the CloudTaser Helm chart and install the operator and eBPF agent:

# Install CloudTaser
helm install cloudtaser oci://ghcr.io/skipopsltd/cloudtaser \
  --namespace cloudtaser-system \
  --create-namespace \
  --set operator.vaultAddress=https://vault.eu.example.com

Verify the installation:

kubectl get pods -n cloudtaser-system

Expected output:

NAME                                  READY   STATUS    RESTARTS   AGE
cloudtaser-operator-abc123-xyz        1/1     Running   0          30s
cloudtaser-ebpf-node1                 1/1     Running   0          30s

Step 3: Configure Vault Connection¶

Use the CloudTaser CLI to connect your cluster to the vault. This creates a ServiceAccount in the cluster for vault token review and configures the Kubernetes auth backend in vault.

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

This command performs three actions:

Creates a ServiceAccount and ClusterRoleBinding in the cluster for vault token review
Enables and configures the Kubernetes auth backend in vault
Creates a vault role (default: cloudtaser) for pod authentication

Preview before applying

Use --dry-run to see what changes will be made before applying them:

cloudtaser connect \
  --vault-address https://vault.eu.example.com \
  --vault-token hvs.YOUR_ADMIN_TOKEN \
  --dry-run

Step 4: Discover Existing Secrets¶

Scan your cluster for workloads that reference Kubernetes Secrets:

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

This scans all Deployments, StatefulSets, and DaemonSets for secretKeyRef, secretRef, and Vault injector annotations. It outputs SecretMapping CRD YAML to stdout.

Discover and applyScan a specific namespacePreview only

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

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

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

Step 5: Annotate a Deployment for Injection¶

Add CloudTaser annotations to your deployment to enable secret injection:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
      annotations:
        cloudtaser.io/inject: "true"
        cloudtaser.io/vault-address: "https://vault.eu.example.com"
        cloudtaser.io/vault-role: "cloudtaser"
        cloudtaser.io/secret-paths: "secret/data/myapp/config"
        cloudtaser.io/env-map: "db_password=PGPASSWORD,api_key=API_KEY"
    spec:
      containers:
        - name: myapp
          image: myapp:latest

Apply the deployment:

kubectl apply -f myapp-deployment.yaml

When the pod starts, the CloudTaser operator:

Injects an init container that copies the wrapper binary to a memory-backed emptyDir (/cloudtaser/)
Rewrites the container entrypoint to /cloudtaser/wrapper
The wrapper authenticates to vault, fetches secrets, and fork+execs your application with secrets as environment variables (PGPASSWORD, API_KEY)

Secrets exist only in process memory

They never touch etcd, Kubernetes Secrets, or disk.

Annotation Reference¶

Annotation	Required	Description
`cloudtaser.io/inject`	Yes	Set to `"true"` to enable injection
`cloudtaser.io/vault-address`	Yes	Vault/OpenBao endpoint URL
`cloudtaser.io/vault-role`	Yes	Vault Kubernetes auth role name
`cloudtaser.io/secret-paths`	Yes	Comma-separated vault KV v2 paths
`cloudtaser.io/env-map`	Yes	Vault field to env var mappings (e.g., `password=PGPASSWORD`)
`cloudtaser.io/rotation`	No	Rotation strategy: `restart`, `sighup`, or `none` (default: `none`)
`cloudtaser.io/config`	No	Reference a CloudTaserConfig CR instead of per-pod annotations

Full configuration reference

For the complete list of annotations, CRDs, and Helm values, see Configuration.

Step 6: Verify Protection¶

Check the status of CloudTaser components and protected workloads:

Cluster-wide statusNamespace-specific status

cloudtaser status

cloudtaser status -n default

This reports operator health, webhook status, eBPF enforcement coverage, and per-workload protection status.

Run Validation¶

Run validation to verify the full stack is working correctly:

Basic validationWith vault auth verification

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

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

Validation checks include:

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

Step 7: Run an Audit¶

Generate a data sovereignty compliance audit report:

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

The audit scans all workloads and reports:

Protected workloads -- CloudTaser-injected
Unprotected workloads -- still using K8s Secrets directly
Orphaned secrets in etcd
eBPF runtime enforcement coverage

JSON output (for CI/CD or compliance tooling)Namespace-specific audit

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

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

Next Steps¶

Installation Guide -- Production installation and hardening
Security Model -- Trust boundaries and threat model
Troubleshooting -- Common issues and solutions
Compliance Mapping -- GDPR, NIS2, DORA, and Schrems II alignment