Kubernetes uses Public Key Infrastructure (PKI) to authenticate and encrypt communications between system components, involving multiple certificate authorities (CAs) for enhanced security. Protecting private key files and minimizing client certificate use are critical, as Kubernetes currently lacks certificate revocation mechanisms. #KubernetesPKI #kubeadm #etcd #CertificateAuthority
Keypoints
- Kubernetes secures inter-component communication using TLS connections authenticated via PKI.
- Three distinct certificate authorities (CAs) are employed: the main Kubernetes CA, the etcd CA, and the front-proxy CA, each serving different security purposes.
- The API server to kubelet connection is unauthenticated by default, exposing it to adversary-in-the-middle (AITM) attacks.
- Private key files, especially the main CA private key (ca.key), must be securely stored to prevent cluster-wide compromise.
- Kubernetes lacks certificate revocation mechanisms such as CRLs or OCSP, complicating the removal of compromised client certificates.
- Client certificates should be minimized for authentication, with ordinary users discouraged from using them due to revocation challenges.
- Kubernetes distributions may differ in how they store sensitive keys, requiring awareness of distribution-specific security implications.
MITRE Techniques
- [T1550] Use of PKI for Authentication – Kubernetes uses Public Key Infrastructure to authenticate and encrypt connections between system components, enhancing secure communication (“…authenticate connections between Kubernetes system components and to encrypt the data transferred…”).
- [T1587] Develop Capabilities: Compromise CA Private Keys – An attacker gaining access to the main Kubernetes CA private key (ca.key) could create new privileged credentials, leading to persistent admin access (“…An attacker who gets access to that file will have persistent cluster-admin level access…”).
- [T1078] Valid Accounts Without Revocation – Kubernetes does not support certificate revocation lists or protocols, so compromised client certificates cannot be individually revoked (“…there is no method of revoking individual certificates…”).
- [T1190] Exploit Public-Facing Application – The unauthenticated API server to kubelet connection allows risk of adversary-in-the-middle attacks (“…the connection from the API server to the kubelet…is open to AITM attacks…”).
Indicators of Compromise
- [File Path] Kubernetes control plane certificate files – /etc/kubernetes/pki/ca.key, /etc/kubernetes/pki/apiserver.crt
- [File Path] Kubelet PKI files – /var/lib/kubelet/pki/kubelet-client-current.pem, /var/lib/kubelet/pki/kubelet.crt
Read more: https://securitylabs.datadoghq.com/articles/kubernetes-security-fundamentals-part-7/