Description
--peer-client-cert-auth=false alone does not establish that etcd peer certificate authentication is disabled. In etcd 3.4, specifying --peer-trusted-ca-file also enables certificate authentication on HTTPS peer connections. Review the actual peer CA and HTTPS configuration together.
etcd peer traffic directly supports data replication and cluster consensus, so mutual authentication matters. Client API authentication and peer authentication must be configured separately.
Potential impact
Unauthorized parties with access to the peer network may not be distinguished by certificates. If other controls are also insufficient, replication data and cluster operation can be put at risk.
Remediation
- Set
--peer-client-cert-auth=trueand--peer-trusted-ca-file. - Configure each peer's certificate, key and HTTPS peer addresses, and manage file permissions and certificate renewal.
- Restrict access to the peer network and verify normal peer connections and rejection of untrusted certificates after the change.
Examples
These excerpts compare arguments from a historical etcd version. Actual deployments also require peer certificates and keys, a trusted CA and HTTPS addresses.
Before
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-etcd-deployment
spec:
template:
spec:
containers:
- name: database
image: gcr.io/google_containers/etcd:v3.2.18
command: ["etcd"]
args: ["--peer-client-cert-auth=false"]
The argument is false, but the peer CA and HTTPS settings can still enable certificate authentication. Verify that actual connections require trusted peer certificates.
After
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-etcd-deployment
spec:
template:
spec:
containers:
- name: database
image: gcr.io/google_containers/etcd:v3.2.18
command: ["etcd"]
args: ["--peer-client-cert-auth=true"]
This requires peer certificate verification. Prepare the peer CA, certificates and keys; enabling the option alone does not complete the peer TLS setup.