iCompaas Support

Profile Applicability:
 • Level 1

Description:
 Ensure that the Kubelet is configured to authenticate using certificates by setting the client certificate authority (CA) file.

Rationale:
When Kubelet is authenticated using certificates, the apiserver uses the client certificate to verify the authenticity of the Kubelet before any interaction occurs. This ensures the connection is secure, preventing man-in-the-middle attacks. Without client certificate authentication, connections from the apiserver to Kubelet could be intercepted, compromising the cluster.

Impact:
 Pros:

• Secures Kubelet connections by enforcing certificate-based authentication.

• Prevents man-in-the-middle attacks and ensures the integrity of the connection.

• Improves overall security by ensuring mutual authentication between the apiserver and Kubelet.

Cons:

• Requires TLS to be configured both on the apiserver and the Kubelets.

• Adds complexity in configuration and maintenance.

Default Value:
 The default setting might vary based on the Kubernetes distribution. Check AWS EKS documentation for default values.

Pre-requisites:

• Access to worker nodes via SSH or Session Manager.

• Ability to modify Kubelet configurations and restart services.

• Kubernetes access to test via /configz or deploy privileged pods.

Remediation

Test Plan:

Using AWS Console:

1. SSH into the worker node and run the following command to find the Kubelet process:
   ps -ef | grep kubelet

2. Identify the path of the configuration file from the --config argument.

3. Open the Kubelet configuration file to check if a client CA file is configured:
   sudo less /path/to/kubelet-config.json

4. Look for the following entry:
   "authentication": { "x509": { "clientCAFile": <path/to/client-ca-file> } }

Using AWS CLI:

1. Get the list of nodes in your cluster:
   

   kubectl get nodes

2. Start a proxy to the Kubernetes API:
   

   kubectl proxy --port=8080

3. In a separate terminal, for each node, run:
   

   export NODE_NAME=my-node-name
   curl http://localhost:8080/api/v1/nodes/${NODE_NAME}/proxy/configz

4. Verify that the client CA file is configured by checking the returned JSON for:
   

   "authentication": { "x509": { "clientCAFile": <path/to/client-ca-file> } }

Implementation Plan

Using AWS Console:

1. SSH into the worker node and find the Kubelet configuration file via ps -ef | grep kubelet.

2. Open the file:
   sudo less /path/to/kubelet-config.json

3. Add or modify the following entry to configure the client CA file:
   "authentication": { "x509": { "clientCAFile": <path/to/client-ca-file> } }

4. Save the file and exit.

Using AWS CLI:

1. Locate and edit the Kubelet systemd service file (e.g., /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf for Amazon Linux or Bottlerocket AMIs).

2. Add the following argument to the KUBELET_ARGS variable:
   

   --client-ca-file=<path/to/client-ca-file>

3. Reload systemd and restart the Kubelet service:
   

systemctl daemon-reload
 systemctl restart kubelet.service
systemctl status kubelet -l

Backout Plan

Using AWS Console:

1. If using a configuration file, revert the file to its previous version without the clientCAFile entry.

2. If using systemd arguments, remove the --client-ca-file argument and restart the Kubelet service.

Using AWS CLI:

1. Remove the --client-ca-file flag from the systemd unit or revert to the previous configuration file version if backed up.

2. Restart the Kubelet service:
   

   systemctl daemon-reload
   systemctl restart kubelet.service

References:

1. Kubelet CLI Reference

2. Kubelet Authentication and Authorization

3. Kubelet Config API