Description
In older kube-apiserver configurations, --kubelet-https=false selects HTTP instead of HTTPS for kubelet connections. Requests and responses can be intercepted or changed along an unprotected network path.
Using HTTPS and verifying the kubelet serving certificate are separate controls. Configure encryption, server identity verification and access control together.
Potential impact
- Logs or node management traffic can be exposed on the network.
- Altered requests or responses can compromise the integrity of operational tasks.
Remediation
- Remove
--kubelet-https=falsefrom older configurations supporting it and configure HTTPS using settings supported by your version. - Configure kubelet CA verification and required client authentication and authorization.
- Verify successful node management operations and ensure certificate validation failures are not bypassed.
Examples
These historical examples use Kubernetes 1.6.0. Use settings supported by your current deployment version.
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: ["--kubelet-https=false"]
HTTPS for kubelet is explicitly disabled. If HTTP is used, that traffic has no TLS protection.
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"]
The HTTPS-disabling argument is removed. Also verify that actual connections use HTTPS and validate the serving certificate.