With this integration, the results of the CIS Kubernetes Benchmark and CIS Amazon EKS Benchmark checks run by kube-bench can now be centrally managed in AWS Security Hub.
What is CIS Benchmark?
CIS Benchmark is a set of guidelines published by the Center for Internet Security (CIS), a non-profit organization in the United States, for strengthening various operating systems, servers, and cloud environments.
CIS Benchmark is referenced in compliance requirements such as the PCI DSS when it states "industry-accepted system hardening standards".
Checks whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark
kube-bench is a tool that checks whether Kubernetes is deployed securely by running the checks documented in the CIS Kubernetes Benchmark.
Tests are configured with YAML files, making this tool easy to update as test specifications evolve.
CIS Scanning as part of Trivy and the Trivy Operator
Trivy, the all in one cloud native security scanner, can be deployed as a Kubernetes Operator inside a cluster
Both, the Trivy CLI, and the Trivy Operator support CIS Kubernetes Benchmark scanning among several other features.
Quick start
There are multiple ways to run kube-bench.
You can run kube-bench inside a pod, but it will need access to the host's PID namespace in order to check the running processes, as well as access to some directories on the host where config files and other files are stored.
The supplied job.yamlfile can be applied to run the tests as a…
kube-bench supports checking not only the CIS Kubernetes Benchmark, but also the CIS Amazon Elastic Kubernetes Service (EKS) Benchmark and CIS Google Kubernetes Engine (GKE) Benchmark.
What is AWS Security Hub?
AWS Security Hub is a service for aggregating and centrally managing various security data for the entire AWS environment.
Security Hub integrates with many 3rd party security products, as well as AWS services such as Amazon GuardDuty, Inspector, and Macie.
Data can be sent from Security Hub-enabled products to the Security Hub and vice versa.
Internally, the result information is managed in a JSON type format called AWS Security Finding Format (ASFF), so you can import your own data as long as it conforms to this format.
Prerequisites
I have confirmed that the following versions work.
Amazon EKS: 1.17
eksctl: 0.30.0
kube-bench: 0.40.0
Ran the CIS Amazon EKS Benchmark v1.0 check in an EKS cluster.
Enable integration
Search for kube-bench from the Security Hub console integration and click "Accept findings" to see information about the IAM policies required to send the findings to Security Hub.
Select "Accept findings" again on the confirmation screen, and the status will be activated.
Configue IAM Roles
In order for kube-bench to run in an EKS cluster, the pod must have permissions to send check results to Security Hub.
There are two ways to assign access to AWS resources to a Pod.
Using IRSA, you can associate an IAM role with a Kubernetes service account.
This allows you to provide Security Hub access only to pods launched by kube-bench.
Note that if you use an IAM role that is configured for a node group, all Pods running under that group will be assigned access to the Security Hub.
This time we will use IRSA.
If you haven't created an IAM OIDC Provider to use IRSA, do so first!
If you want to send the execution result to Security Hub, you need to edit cfg/eks-1.0/config.yaml and rewrite the AWS account, region and cluster name to be executed before building the image.
Create a service account for kube-bench using a manifest file like the following. Note that the annotations specifies the IAM role that we just created.
Run kube-bench as a Kubernetes job and make sure it exits successfully.
$kubectl apply -f job-eks.yaml -n kube-bench
job.batch/kube-bench created
$kubectl get all -n kube-bench
NAME READY STATUS RESTARTS AGE
pod/kube-bench-q4sbd 0/1 Completed 0 55s
NAME COMPLETIONS DURATION AGE
job.batch/kube-bench 1/1 5s 55s
If the following message is output to the Pod's log and the job fails, please check whether the contents of cfg/eks-1.0/config.yaml are correct.
failed to output to ASFF: finding publish failed: MissingEndpoint: 'Endpoint' configuration is required for this service
Check the findings of Security Hub
Normally, the results of running kube-bench will be output to the Pod's log.
$kubectl logs -f pod/kube-bench-2j2ss -n kube-bench
[INFO] 3 Worker Node Security Configuration
[INFO] 3.1 Worker Node Configuration Files
[PASS] 3.1.1 Ensure that the proxy kubeconfig file permissions are set to 644 or more restrictive (Scored)
[PASS] 3.1.2 Ensure that the proxy kubeconfig file ownership is set to root:root (Scored)
[PASS] 3.1.3 Ensure that the kubelet configuration file has permissions set to 644 or more restrictive (Scored)
[PASS] 3.1.4 Ensure that the kubelet configuration file ownership is set to root:root (Scored)
[INFO] 3.2 Kubelet
[PASS] 3.2.1 Ensure that the --anonymous-auth argument is set to false (Scored)
[PASS] 3.2.2 Ensure that the --authorization-mode argument is not set to AlwaysAllow (Scored)
[PASS] 3.2.3 Ensure that the --client-ca-file argument is set as appropriate (Scored)
[PASS] 3.2.4 Ensure that the --read-only-port argument is set to 0 (Scored)
[PASS] 3.2.5 Ensure that the --streaming-connection-idle-timeout argument is not set to 0 (Scored)
[PASS] 3.2.6 Ensure that the --protect-kernel-defaults argument is set to true (Scored)
[PASS] 3.2.7 Ensure that the --make-iptables-util-chains argument is set to true (Scored)
[PASS] 3.2.8 Ensure that the --hostname-override argument is not set (Scored)
[WARN] 3.2.9 Ensure that the --event-qps argument is set to 0 or a level which ensures appropriate event capture (Scored)
[PASS] 3.2.10 Ensure that the --rotate-certificates argument is not set to false (Scored)
[PASS] 3.2.11 Ensure that the RotateKubeletServerCertificate argument is set to true (Scored)
== Remediations node ==
3.2.9 If using a Kubelet config file, edit the file to set eventRecordQPS: to an appropriate level.
If using command line arguments, edit the kubelet service file
/etc/systemd/system/kubelet.service on each worker node and
set the below parameter in KUBELET_SYSTEM_PODS_ARGS variable.
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service
== Summary node ==
14 checks PASS
0 checks FAIL
1 checks WARN
0 checks INFO
== Summary total ==
14 checks PASS
0 checks FAIL
1 checks WARN
0 checks INFO
If you specify the --asff flag and send the results to Security Hub, only the number of cases imported to Security Hub will be listed in the Pod's log.
$kubectl logs -f pod/kube-bench-q4sbd -n kube-bench
2020/12/12 14:51:07 Number of findings that were successfully imported:1
In the case of this environment, the result was one.
Note that the results will be sent to Security Hub only for items whose check result is FAIL or WARN. If all checks are PASSed, no results will be generated to Security Hub.
If you check the findings in Security Hub console, you will see that the one result sent was successfully captured.
Using Custom Insights
Security Hub has a feature called Custom Insights that allows you to aggregate data by resource or environment using specific grouping condition and filters.
Custom Insights can be created in the Insights section of the Security Hub console by simply setting any grouping condition, filters
For example, if you are using Security Hub in a multi-account configuration, you can use the management account to aggregate the detection results for each member account.
Let's check out an example of a custom insight with the grouping condition set to AWS account ID and the product name Kube-bench set as a filter.
By clicking on the account ID, you will be able to instantly see the kube-bench results for the target account.
Even if you are operating with a single account, you can use it to list the detection results for each EKS cluster by setting the resource ID as a group by condition.