Description
API server and kubelet HTTPS connections need a valid serving certificate and matching private key. Without explicit file settings, a component can generate a self-signed certificate or use an approved issuance process; absent file paths alone do not establish plaintext communication.
Check that clients validate the certificate actually presented against a trusted CA and the correct server name.
Potential impact
- Without serving-certificate verification, clients cannot reliably reject an impersonating server.
- Invalid certificate/key pairs or expired certificates can cause connection failures.
Remediation
- For manually managed files, set
--tls-cert-fileand--tls-private-key-fileto a valid matching pair. Also check kubelet’s TLS configuration-file settings. - If using automatic issuance, verify the approval and renewal process and the clients’ CA trust.
- Restrict private-key access and test certificate names, expiry and actual HTTPS connectivity.
Examples
These historical excerpts show Kubernetes 1.6.0 API server arguments. The filename is illustrative; provide actual PEM certificate/key contents and deployment paths.
Before
apiVersion: v1
kind: Pod
metadata:
name: command-demo
spec:
containers:
- name: command-demo-container
image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
command: ["kube-apiserver"]
args: []
TLS files are not explicitly specified. Inspect the certificate actually generated or supplied and the clients’ verification settings.
After
apiVersion: v1
kind: Pod
metadata:
name: command-demo
spec:
containers:
- name: command-demo-container
image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
command: ["kube-apiserver"]
args: ["--tls-cert-file=someFile.txt", "--tls-private-key-file=someFile.txt"]
Certificate and private-key paths are specified. Do not rely on the example someFile.txt name: verify that the actual files contain the correct certificate and matching key.