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

​
What this check verifies

Etcd pods are assessed for TLS-enabled client communication, indicated by --cert-file and --key-file in container arguments, showing that Kubernetes API state traffic is encrypted in transit.

​
Risk

Without TLS, etcd traffic is exposed on the network, weakening CIA:
  • Confidentiality: leakage of secrets and cluster state
  • Integrity: MITM can alter configs, roles, and objects
  • Availability: control-plane instability from tampered responses

​
Recommendation

Enforce mTLS for etcd client and peer traffic and disable plaintext listeners. Restrict access to etcd to control-plane components via tight network policies and firewalls. Use strong TLS versions/ciphers, rotate certificates, and safeguard keys, applying least privilege and defense in depth.

​
Remediation

Dashboard steps
  1. SSH to the control-plane node
  2. Open /etc/kubernetes/manifests/etcd.yaml
  3. In spec.containers[0].command add:
    • —cert-file=/etc/kubernetes/pki/etcd/server.crt
    • —key-file=/etc/kubernetes/pki/etcd/server.key
  4. Save the file; kubelet will automatically restart the etcd Pod
  5. Confirm the etcd container command now includes both —cert-file and —key-file

​
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_tls_encryption. 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