Skip to content

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:

  1. Creates a ServiceAccount and ClusterRoleBinding in the cluster for vault token review
  2. Enables and configures the Kubernetes auth backend in vault
  3. 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.

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:

  1. Injects an init container that copies the wrapper binary to a memory-backed emptyDir (/cloudtaser/)
  2. Rewrites the container entrypoint to /cloudtaser/wrapper
  3. 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:

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:

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