Right now the command is hardcoded in every check in, f.e. in https://github.com/neuvector/kubernetes-cis-benchmark/blob/master/1.8/worker/worker_1_kubelet.sh

check_argument 'kubelet'

If I run kubelet as hyperkube it will show me wrong results.

I propose to enable to pass that command externally.
F.e.:
Add
CIS_KUBELET_CMD=${CIS_KUBELET_CMD:-kubelet}
and then
check_argument '$CIS_KUBELET_CMD'

In such case I could run:

export CIS_KUBELET_CMD="hyperkube kubelet"
./worker.sh 1.8

If unspecified, --service-account-key-file defaults to --tls-private-key-file.

The benchmark only checks for --<param> whereas the form -<param> is also accepted by etcd.

My kubelet is started with

kubelet --address=192.168.0.10 --allow-privileged --anonymous-auth=false --authentication-token-webhook --authorization-mode=Webhook --cadvisor-port=0 --cluster-dns=10.0.0.10 --cluster-domain=cluster.local --kubeconfig=/etc/kubernetes/kubeconfig-kubelet --pod-manifest-path=/etc/kubernetes/manifests --read-only-port=0 --require-kubeconfig

Yet the benchmark reports

[PASS] 2.1.1  - Ensure that the --allow-privileged argument is set to false

The following files reference a metadata-only audit policy in order to prevent logging request/response contents for sensitive resources:

• https://github.com/neuvector/kubernetes-cis-benchmark/blob/master/1.6.0/master/3_control_plane_configuration.sh
• https://github.com/neuvector/kubernetes-cis-benchmark/blob/master/gke/master/3_control_plane_configuration.sh
• https://github.com/neuvector/kubernetes-cis-benchmark/blob/master/1.5.1/master/3_control_plane_configuration.sh

A recent bugfix resolves logging of subresource requests which would previously fail with an error. The serviceaccounts/token subresource responds to TokenRequest API calls with a newly minted service account token.

The serviceaccounts/token resource should also be included in the metadata-only audit policy if credentials are not intended to appear in the audit log.

When set, the --use-service-account-credentials flag enables the feature. =true is not needed, and the absence of flag means =false.

As per CIS document "Verify that if the --make-iptables-util-chains argument exists then it is set to true"
But in the script it will only make pass if --make-iptables-util-chains=false
Kindly review and correct me if iam wrong

This script claims to test against best practises for k8s clusters and the checks seem to be sound.
Nonetheless are there any sources for these best practises? If so it would be nice to link/explain(?) them in the README.md.

Btw: thank you for mainting this set of scripts!

When set, the --peer-client-cert-auth and --client-cert-auth flags enables the feature. =true is not needed, and the absence of flag means =false.

The option to start this version was seemingly forgotten in these scripts. PR #39 fixes this issue.

The following (correct) permissions yield a warning:

-rw-r-----. 1 root root 1796 Jun 30 19:04 kube-apiserver.json
-rw-r-----. 1 root root 1873 Jun 30 18:58 kube-controller-manager.json
-rw-r-----. 1 root root 1406 Jun 30 18:39 kube-proxy.json
-rw-r-----. 1 root root 1440 Jun 30 18:39 kube-scheduler.json