kubebench profile for Yandex Managed Service for Kubernetes

[mirtov-alexey]

Good afternoon!
We would like to make a contribution to kubebench in order to be able to perform an automated configuration scan for our Yandex Managed Service for Kubernetes® by analogy with eks-1.0.1 and gke-1.0, etc.

We saw a comment on the kubebench page:
"kube-bench implements the CIS Kubernetes Benchmark as closely as possible ..."

We have already contacted the CIS community to create our own CIS Benchmark, but in order not to waste time, we would like to clarify something.

In this regard, there are several questions:

1. Can we contribute our configuration files to the rest by analogy before the release of the official CIS Benchmark? (we also need to add our config file paths to the general config.yaml file)
2. What are the general rules for contributing and instructions for the process?
3. I noticed that, for example, AWS EKS and the basic CIS config is more aimed at automated auditing and only displays specific checks that can be automatically checked, while, for example, GCP GKE shows a lot of manual checks and recommendations (which, in my opinion, makes it difficult and is at odds with the tool concept). Do I understand correctly that it is better to follow the path NOT like the GCP GKE?
4. How can you debug when developing a config? I tried to add my file locally to the / cfg folder, but it seems that without modifying the code it is impossible to connect a new profile

[mozillazg]

How can you debug when developing a config? I tried to add my file locally to the / cfg folder, but it seems that without modifying the code it is impossible to connect a new profile

There is an example of how to add a new benchmark via only updating files in cfg folder:

https://github.com/aquasecurity/kube-bench/compare/main...mozillazg:new-benchmark-demo?expand=1

$ kube-bench run --targets master --benchmark demo-1.0
[INFO] 1 Master Node Security Configuration
[INFO] 1.1 Master Node Configuration Files
[FAIL] 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Automated)

== Remediations master ==
1.1.1 Run the below command (based on the file location on your system) on the
master node.
For example, chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml


== Summary master ==
0 checks PASS
1 checks FAIL
0 checks WARN
0 checks INFO

== Summary total ==
0 checks PASS
1 checks FAIL
0 checks WARN
0 checks INFO

$ kube-bench run --targets node --benchmark demo-1.0
[INFO] 2 Worker Node Security Configuration
[INFO] 2.1 Worker Node Configuration Files
[FAIL] 2.1.1 Ensure that the kubelet service file permissions are set to 644 or more restrictive (Automated)

== Remediations node ==
2.1.1 Run the below command (based on the file location on your system) on the each worker node.
For example,
chmod 644 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf


== Summary node ==
0 checks PASS
1 checks FAIL
0 checks WARN
0 checks INFO

== Summary total ==
0 checks PASS
1 checks FAIL
0 checks WARN
0 checks INFO

[mozillazg]

I noticed that, for example, AWS EKS and the basic CIS config is more aimed at automated auditing and only displays specific checks that can be automatically checked, while, for example, GCP GKE shows a lot of manual checks and recommendations (which, in my opinion, makes it difficult and is at odds with the tool concept). Do I understand correctly that it is better to follow the path NOT like the GCP GKE

Yes, it's better to follow benchmarks like basic cis and eks.

[mirtov-alexey]

@mozillazg Thank you very much!
i will try this solution and after this i will create pr with our config

[yoavrotems]

Hey as @mozillazg answered you can see how to run a new benchmark for debugging and yes this is a good point to start by using basic cis and go from there.

Can we contribute our configuration files to the rest by analogy before the release of the official CIS Benchmark? (we also need to add our config file paths to the general config.yaml file)

Mostly we accepting CIS approved benchmarks, but in some cases with strong validation we do accept other. for example redhat ocp hardening guide, we worked with the fellows in redhat about it and accept it because they are the ocp creators (two years later it really become CIS and rhel collaboration).

What are the general rules for contributing and instructions for the process?

You can read CONTRIBUTING.md about our guide line,
About a complete config contributing if its not yet in CIS we would need to discuss about it, and validate it's integrity.
If you are from Yandex and want to contribute about Yandex Managed Service for Kubernetes®. This answers the integrity question but we will still need to see env where the tests are running and also could FAIL/PASS so we could see there aren't any false positives and etc.

I noticed that, for example, AWS EKS and the basic CIS config is more aimed at automated auditing and only displays specific checks that can be automatically checked, while, for example, GCP GKE shows a lot of manual checks and recommendations (which, in my opinion, makes it difficult and is at odds with the tool concept). Do I understand correctly that it is better to follow the path NOT like the GCP GKE?

About GKE you are right it's better not to be like that, there are a few reasons for that,

• less control in GKE, but the tests are still there to show in compare to those tests in CIS
• GKE is a lot about GUI and its making it hard to be fully automated
  In the end of the road kube-bench is here to automate checks for hardening, but it also a CIS approved tool, so we do support also stuff that are not fully automated by structure.

How can you debug when developing a config? I tried to add my file locally to the / cfg folder, but it seems that without modifying the code it is impossible to connect a new profile

I think @mozillazg covered this part ( P.S you are welcome to make a PR about it into contribution in docs)

[mirtov-alexey]

Colleagues, thank you very much for the information.

I prepared a pull request #1069
and described all the details and questions in the comments to it. Please take a look and give feedback. I seem to have found some inconsistencies.
@mozillazg @yoavrotems