Etcd uses a CA distinct from the API server CA

​

What this check verifies

Etcd configuration is assessed to ensure it trusts a unique Certificate Authority via --trusted-ca-file, distinct from the API server’s --client-ca-file. If the same CA file is used, etcd shares the cluster CA; differing files imply separation, though CA content should still be verified.

​

Risk

Using the Kubernetes CA for etcd allows any cert signed by that CA to authenticate to the datastore. Theft or mis-issuance enables unauthorized reads/writes, causing secret exposure (confidentiality), state tampering (integrity), and potential control-plane disruption (availability).

​

Recommendation

Adopt a separate PKI for etcd: issue client and peer certs from an etcd-only CA and trust only that CA. Enforce mTLS (--client-cert-auth, --peer-client-cert-auth), avoid --auto-tls, rotate keys independently, and apply least privilege to CA issuance with regular certificate audits.

​

Remediation

Dashboard steps

1. SSH to a control-plane node that runs etcd
2. Open the API server manifest: sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml and note the value of —client-ca-file=<APISERVER_CA_PATH>
3. Ensure an etcd-specific CA file exists at a different path (for example: /etc/kubernetes/pki/etcd/ca.crt) and is readable by the etcd container
4. Edit the etcd manifest: sudo vi /etc/kubernetes/manifests/etcd.yaml
   • In the etcd container command/args, add or update: —trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt (this path must NOT equal <APISERVER_CA_PATH>)
   • Save the file; the kubelet will restart the etcd pod automatically
5. Verify the change: kubectl -n kube-system get pods -o wide | grep etcd, then describe the etcd pod and confirm —trusted-ca-file points to a different path than the API server —client-ca-file

​

References

• https://etcd.io/docs/latest/op-guide/security/
• https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#limiting-access-of-etcd-clusters

​

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_unique_ca. 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