Capture Cluster etcd Snapshot for Control-Plane Forensics
Capture a point-in-time etcd snapshot so attacker changes to RBAC, secrets, CRDs, and other cluster objects can be compared against a trusted baseline later. Treat the snapshot as top-sensitivity evidence.
Actions
- 1
Identify cluster flavor: self-managed clusters allow direct etcd snapshot; managed clusters (EKS, GKE, AKS) require provider-specific backup paths.
- 2
For self-managed: `ETCDCTL_API=3 etcdctl snapshot save /tmp/etcd-snapshot.db` with cluster certificates.
- 3
Verify the snapshot with `etcdctl snapshot status --write-out=table`.
- 4
Hash the snapshot with SHA-256 and record cluster identity, timestamp, and etcd version.
- 5
Encrypt the snapshot at rest before transport; it contains every cluster secret in plaintext unless encryption-at-rest was configured on etcd.
- 6
Store in the highest-sensitivity evidence tier with strict chain-of-custody.
Queries
ETCDCTL_API=3 etcdctl snapshot status /tmp/etcd-snapshot.db --write-out=table
etcdctl member list
Notes
Managed clusters rarely allow direct etcd access; use provider backup features and note the opacity of the snapshot content.
Encryption-at-rest for etcd (Secrets KMS) is a pre-incident investment that dramatically reduces the sensitivity of this snapshot.
Every cluster Secret is in this file -- treat accordingly.