etcd
Cloud Native Computing Foundationdatabase4 credentials
Unauthenticated Default Client Access
etcd / unauthenticated-default
etcd client authentication is disabled unless auth is explicitly enabled. In an auth-disabled deployment, clients can read and write through exposed etcd client endpoints without presenting a username, password, token, or client certificate, unless network or TLS controls block them.
Unauthenticated access
open defaultno authentication required- username
- none
- password
- none
Location
http://<host>:2379, https://<host>:2379etcd client API listener when auth is disabled or unauthenticated clients are accepted
etcd flags/config, static pod manifest, systemd unit--auth-token, auth enable state, client-cert-auth, trusted-ca-file, and listen/advertise client URLs determine whether credentials or mTLS are required
etcd startup logs and etcdctl auth status output showing auth disabled/enabled state
Notes
This represents absence of etcd username/password authentication, not a blank password. Exposure depends on listen URLs, firewalling, Kubernetes control-plane network isolation, TLS client-auth settings, and whether `etcdctl auth enable` has been run.
etcd User Password
etcd / client-user-password
etcd can enable username/password authentication for client access. Users and roles control access to keys and ranges once auth is enabled.
Location
etcd client API, etcdctl, gRPC gateway, and Kubernetes apiserver-to-etcd accessetcd auth store containing users, roles, and password verifier state
etcd static pod manifests, systemd units, etcdctl scripts, and deployment manifests
ETCDCTL_USER, ETCDCTL_PASSWORDKubernetes Secrets, Vault entries, and cluster bootstrap secret stores
etcd server logs, audit output, and etcdctl traces
Client / Peer TLS Private Key
etcd / client-peer-tls-key
etcd commonly uses mutual TLS for client and peer authentication. Client, server, and peer certificate private keys grant access to the cluster or quorum communication path.
Looks like
pattern-----BEGIN (RSA |EC |OPENSSH |ENCRYPTED |)PRIVATE KEY-----Location
/etc/kubernetes/pki/etcd/, /etc/etcd/etcd client, server, peer, and CA certificate/key files
Kubernetes Secrets, PKI vaults, and backup key stores
cluster backups, kubeadm cert bundles, support bundles, and disaster recovery archives
Bootstrap, Snapshot, and Encryption Secret
etcd / bootstrap-token-and-snapshot-secret
etcd deployments often store bootstrap credentials, backup/snapshot credentials, and Kubernetes secrets data inside etcd. Exposure of snapshots can expose all Kubernetes Secret values unless separately encrypted.
Location
etcd snapshots, disaster recovery backups, and copied data directories
backup scripts, snapshot cron jobs, static pod manifests, and encryption provider configs
backup vaults and cloud object storage credentials
etcd keyspace including Kubernetes Secret objects or application secrets
Notes
An etcd snapshot is often credential-equivalent in Kubernetes environments because it may contain all cluster Secret resources.
Scope
Authorized use
LOLCreds helps map the credential surface of real products: known defaults, generated values, credential locations, and exposure patterns.