CIS Kubernetes Benchmark and connectors
Which connectors provide evidence for CIS Kubernetes Benchmark, for which controls, and how to connect them.
Safeguard's automated tests map to 60 recommendations of CIS Kubernetes Benchmark v1.9.0. 41 tests apply: 41 read a connected system, and 0 read Safeguard's own records (policies, people, training and devices), so they need no connector. A passing result is evidence toward a control, not proof that the control is met on its own.
A CIS benchmark is a catalogue mapping: results show on the tests, filters and evidence with their recommendation numbers, and the benchmark is not a framework in your library.
How to connect for this framework
- Connect the systems you run from the table below. Each connector links to its setup steps.
- Open Compliance › Tests and filter by the benchmark to see its results.
- Tests run on their schedule, or straight away with Run now on Compliance › Tests. A passing test counts toward its controls once its preview period has ended.
Automated tests are switched on per workspace by the Safeguard team.
Connectors with automated evidence (1)
| Connector | Controls it provides evidence for | Tests |
|---|---|---|
| Kubernetes (also Gatekeeper OPA, Kyverno) | 1.2.1, 1.2.10, 1.2.12, 1.2.13, 1.2.14, 1.2.15, 1.2.16, 1.2.17, 1.2.18, 1.2.19, 1.2.2, 1.2.21, 1.2.22, 1.2.23, 1.2.24, 1.2.25, 1.2.26, 1.2.27, 1.2.29, 1.2.4, 1.2.5, 1.2.6, 1.2.7, 1.2.8, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.7, 1.4.1, 1.4.2, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 5.1.10, 5.1.11, 5.1.12, 5.1.13, 5.1.2, 5.1.3, 5.1.4, 5.1.5, 5.1.6, 5.1.8, 5.1.9, 5.2.1, 5.2.10, 5.2.11, 5.2.12, 5.2.13, 5.2.6, 5.2.7, 5.2.8, 5.2.9, 5.4.1, 5.7.2, 5.7.4 | 41 |
Recommendations (60)
| Recommendation | Title | Automated tests | Connectors |
|---|---|---|---|
1.2.1 | API server refuses anonymous requests | 1 | 3 |
1.2.2 | API server reads no static token file | 1 | 3 |
1.2.4 | API server presents a client certificate to kubelets | 1 | 3 |
1.2.5 | API server verifies kubelet serving certificates | 1 | 3 |
1.2.6 | API server authorization is never AlwaysAllow | 1 | 3 |
1.2.7 | API server authorizes kubelets with the Node authorizer | 1 | 3 |
1.2.8 | API server authorizes with RBAC | 1 | 3 |
1.2.10 | AlwaysAdmit admission plugin is off | 1 | 3 |
1.2.12 | ServiceAccount admission plugin is on | 1 | 3 |
1.2.13 | NamespaceLifecycle admission plugin is on | 1 | 3 |
1.2.14 | NodeRestriction admission plugin is on | 1 | 3 |
1.2.15 | API server profiling endpoint is off | 1 | 3 |
1.2.16 | API server writes an audit log | 1 | 3 |
1.2.17 | API server keeps audit logs for at least 30 days | 1 | 3 |
1.2.18 | API server keeps at least 10 rotated audit logs | 1 | 3 |
1.2.19 | API server rotates audit logs at 100 MB or more | 1 | 3 |
1.2.21 | API server checks service account tokens against etcd | 1 | 3 |
1.2.22 | API server has a service account verification key | 1 | 3 |
1.2.23 | API server authenticates to etcd with a client certificate | 1 | 3 |
1.2.24 | API server serves TLS with its own certificate | 1 | 3 |
1.2.25 | API server verifies client certificates against a CA | 1 | 3 |
1.2.26 | API server verifies etcd's certificate against a CA | 1 | 3 |
1.2.27 | API server encrypts stored resources with a provider config | 1 | 3 |
1.2.29 | API server offers only strong TLS cipher suites | 1 | 3 |
1.3.2 | Controller manager profiling endpoint is off | 1 | 3 |
1.3.3 | Controller manager uses one service account per controller | 1 | 3 |
1.3.4 | Controller manager signs service account tokens with a key | 1 | 3 |
1.3.5 | Controller manager hands pods the cluster root CA | 1 | 3 |
1.3.7 | Controller manager listens on loopback only | 1 | 3 |
1.4.1 | Scheduler profiling endpoint is off | 1 | 3 |
1.4.2 | Scheduler listens on loopback only | 1 | 3 |
2.1 | etcd serves client TLS with a certificate | 1 | 3 |
2.2 | etcd requires client certificates | 1 | 3 |
2.3 | etcd uses no self-signed automatic client TLS | 1 | 3 |
2.4 | etcd peers use TLS certificates | 1 | 3 |
2.5 | etcd requires peer certificates | 1 | 3 |
2.6 | etcd uses no self-signed automatic peer TLS | 1 | 3 |
5.1.2 | Few roles can read Secrets | 1 | 3 |
5.1.3 | Roles avoid wildcards | 1 | 3 |
5.1.4 | Few roles can create pods | 1 | 3 |
5.1.5 | Default service accounts are not used | 1 | 3 |
5.1.6 | Service account tokens are mounted only where needed | 1 | 3 |
5.1.8 | Bind, impersonate and escalate are rarely granted | 1 | 3 |
5.1.9 | Few roles can create persistent volumes | 1 | 3 |
5.1.10 | Few roles can reach the nodes proxy | 1 | 3 |
5.1.11 | Few roles can approve certificate requests | 1 | 3 |
5.1.12 | Few roles can change admission webhooks | 1 | 3 |
5.1.13 | Few roles can mint service account tokens | 1 | 3 |
5.2.1 | An admission policy mechanism is active | 2 | 3 |
5.2.6 | Containers cannot escalate privileges | 1 | 3 |
5.2.7 | Containers do not run as root | 1 | 3 |
5.2.8 | Containers drop NET_RAW | 1 | 3 |
5.2.9 | Containers add no Linux capabilities | 1 | 3 |
5.2.10 | Containers drop all Linux capabilities | 1 | 3 |
5.2.11 | No Windows HostProcess containers | 1 | 3 |
5.2.12 | No hostPath volumes | 1 | 3 |
5.2.13 | No host ports | 1 | 3 |
5.4.1 | Secrets are mounted as files, not environment variables | 1 | 3 |
5.7.2 | Pods use the RuntimeDefault seccomp profile | 1 | 3 |
5.7.4 | Workloads stay out of the default namespace | 1 | 3 |
CIS Google Cloud Platform Foundations Benchmark and connectors
Which connectors provide evidence for CIS Google Cloud Platform Foundations Benchmark, for which controls, and how to connect them.
Trust Center setup
Publish a public Trust Center that shows your compliance status, controls, policies, subprocessors and documents, and keep it current.