소스 정보
- 저장소
- CyberStrikeus/CyberStrike
- 최근 소스 활동
- 2026년 4월 22일 14:54
- 감지된 SKILL.md 언어
- 영어
- 스타
- 1,653
- 포크
- 254
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
메뉴
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/CyberStrikeus/CyberStrike --skill cis-eks-v160-3-2-3명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | cis-eks-v160-3.2.3 |
| description | Ensure that a Client CA File is Configured (Automated) |
| category | cis-eks |
| version | 1.6.0 |
| author | cyberstrike-official |
| tags | ["cis","eks","kubernetes","aws","worker-node","kubelet","authentication","tls","certificates"] |
| cis_id | 3.2.3 |
| cis_benchmark | CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.6.0 |
| tech_stack | ["kubernetes","aws","eks"] |
| cwe_ids | [] |
| chains_with | [] |
| prerequisites | [] |
| severity_boost | {} |
Enable Kubelet authentication using certificates.
The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet's port-forwarding functionality. These connections terminate at the kubelet's HTTPS endpoint. By default, the apiserver does not verify the kubelet's serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. Enabling Kubelet certificate authentication ensures that the apiserver could authenticate the Kubelet before submitting any requests.
You require TLS to be configured on apiserver as well as kubelets.
Audit Method 1:
Kubelets can accept configuration via a configuration file and in some cases via command line arguments. It is important to note that parameters provided as command line arguments will override their counterpart parameters in the configuration file (see --config details in the Kubelet CLI Reference for more info).
With this in mind, it is important to check for the existence of command line arguments as well as configuration file entries when auditing Kubelet configuration.
Firstly, SSH to each node and execute the following command to find the Kubelet process:
ps -ef | grep kubelet
The output of the above command provides details of the active Kubelet process, from which we can see the command line arguments provided to the process. Also note the location of the configuration file, provided with the --config argument, as this will be needed to verify configuration. The file can be viewed with a command such as more or less, like so:
sudo less /path/to/kubelet-config.json
Verify that a client certificate authority file is configured. This may be configured using a command line argument to the kubelet service with --client-ca-file or in the kubelet configuration file via "authentication": { "x509": {"clientCAFile": <path/to/client-ca-file> } }.
Audit Method 2:
It is also possible to review the running configuration of a Kubelet via the /configz endpoint of the Kubernetes API. This can be achieved using kubectl to proxy your requests to the API.
Discover all nodes in your cluster by running the following command:
kubectl get nodes
Next, initiate a proxy with kubectl on a local port of your choice. In this example we will use 8080:
kubectl proxy --port=8080
With this running, in a separate terminal run the following command for each node:
export NODE_NAME=my-node-name
curl http://localhost:8080/api/v1/nodes/${NODE_NAME}/proxy/configz
The curl command will return the API response which will be a JSON formatted string representing the Kubelet configuration.
Verify that a client certificate authority file is configured with "authentication": { "x509": {"clientCAFile": <path/to/client-ca-file> } } in the API response.
Remediation Method 1:
If configuring via the Kubelet config file, you first need to locate the file. To do this, SSH to each node and execute the following command to find the kubelet process:
ps -ef | grep kubelet
The output of the above command provides details of the active kubelet process, from which we can see the location of the configuration file provided to the kubelet service with the --config argument. The file can be viewed with a command such as more or less, like so:
sudo less /path/to/kubelet-config.json
Configure the client certificate authority file by setting the following parameter appropriately:
"authentication": { "x509": {"clientCAFile": <path/to/client-ca-file> } }
Remediation Method 2:
If using executable arguments, edit the kubelet service file on each worker node and ensure the below parameters are part of the KUBELET_ARGS variable string.
For systems using systemd, such as the Amazon EKS Optimised Amazon Linux or Bottlerocket AMIs, then this file can be found at /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf. Otherwise, you may need to look up documentation for your chosen operating system to determine which service manager is configured:
--client-ca-file=<path/to/client-ca-file>
For Both Remediation Steps:
Based on your system, restart the kubelet service and check the service status. The following example is for operating systems using systemd, such as the Amazon EKS Optimised Amazon Linux or Bottlerocket AMIs, and invokes the systemctl command. If systemctl is not available then you will need to look up documentation for your chosen operating system to determine which service manager is configured:
systemctl daemon-reload
systemctl restart kubelet.service
systemctl status kubelet -l
See the EKS documentation for the default value.
| Controls Version | Control | IG 1 | IG 2 | IG 3 |
|---|---|---|---|---|
| v8 | 3.10 Encrypt Sensitive Data in Transit | X | X | |
| v7 | 14.4 Encrypt All Sensitive Information in Transit | X | X |