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

​
What this check verifies

Etcd is configured to require TLS client certificate authentication when the etcd container includes --client-cert-auth, so client access is validated with trusted certificates.

​
Risk

Without mTLS client auth, any reachable client can query or mutate etcd:
  • Confidentiality: exposure of Secrets and cluster metadata
  • Integrity: tampering with RBAC, pods, and configs
  • Availability: destructive writes can disrupt the control plane

​
Recommendation

Enforce mutual TLS for etcd clients by requiring validated certificates (--client-cert-auth=true) issued by a trusted CA. Restrict network access to etcd to API servers, rotate keys regularly, and apply least privilege and separation of duties for certificate management.

​
Remediation

# Enable client certificate authentication on etcd
resource "kubernetes_pod" "<example_resource_name>" {
  metadata {
    name      = "<example_resource_name>"
    namespace = "kube-system"
  }
  spec {
    container {
      name  = "etcd"
      image = "gcr.io/etcd-development/etcd:v3.5.13"
      command = [
        "etcd",
        "--client-cert-auth=true" # Critical: enables client cert auth to pass the check
      ]
    }
  }
}

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