Check ID: etcd_peer_tls_config
Provider: Kubernetes
Service: etcd
Severity: HIGH
Categories: encryption, cluster-security
Resource type: Pod

​
What this check verifies

Etcd peer communication is treated as secure when TLS is configured with a peer certificate and key (e.g., --peer-cert-file and --peer-key-file). The assessment inspects etcd containers for these options to determine whether server-to-server traffic is encrypted and authenticated.

​
Risk

Without TLS on peer links, attackers can intercept or alter Raft traffic, enabling node impersonation and consensus manipulation. This endangers confidentiality (exposed cluster state), integrity (tampered writes), and availability (quorum disruption), cascading into control-plane instability.

​
Recommendation

Enforce TLS for etcd peer communication with unique certificates per member and mutual authentication. Apply strong cipher suites and modern protocol versions, rotate keys, and separate CAs for peers and clients. Limit network access to peer ports to trusted nodes, following least privilege and defense in depth.

​
Remediation

resource "kubernetes_pod" "<example_resource_name>" {
  metadata {
    name = "<example_resource_name>"
  }
  spec {
    container {
      name  = "etcd"
      image = "quay.io/coreos/etcd:latest"
      command = [
        "etcd",
        "--peer-cert-file=</path/to/peer-cert-file>", # Critical: enables TLS for peer connections
        "--peer-key-file=</path/to/peer-key-file>"   # Critical: key for the peer TLS cert
      ]
    }
  }
}

​
References

​
Where this check fires

This check runs on every scheduled scan against your Kubernetes account. Findings appear at Cloud Security → Findings filterable by Check ID = etcd_peer_tls_config. To re-evaluate after a fix, hit Run now on the account’s schedule under Cloud Security → Schedules — the next scan re-checks this control and marks the finding fixed or keeps it persistent.
← Back to Kubernetes checks