Review etcd peer TLS certificate and key settings

Description

etcd peer communication supports data replication and consensus between members. Encrypt peer connections with trusted certificates and matching private keys, and verify the identity of the other members.

Certificate and key paths alone do not complete mutual TLS. Configure HTTPS peer URLs, a trusted CA and peer-certificate verification together.

Potential impact

Someone who intercepts an unprotected peer path can read or modify traffic.
Incorrect or expired certificates and keys can break peer connectivity and affect cluster availability.

Remediation

For manually configured certificates, supply a matching certificate and key through --peer-cert-file and --peer-key-file. Restrict access to the private key.
Use HTTPS for peer listen and advertised URLs, and verify trusted peer certificates with --peer-trusted-ca-file and --peer-client-cert-auth.
Review certificate names, validity and renewal procedures. Verify peer connectivity and cluster health after changes; review TLS for client connections separately.

Examples

These historical etcd 3.2.18 excerpts show container arguments. The full Deployment, file mounts and peer URLs are omitted. Use a supported version for new deployments.

Before

yaml

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-cert-file=/etc/env/file.crt"

This supplies a peer certificate without its matching private key. The key is needed to complete the intended manual TLS configuration.

After