support for CIS Benchmark version 1.5

[winnettjohnston]

Great tool! The kubernetes CIS benchmark 1.5 was released. What is the timeline to align with the new benchmark?

[jcmcken]

Also interested in this.

[robertojrojas]

Note that we changed the cfg directory layout to use the CIS Benchmark version instead of the Kubernetes as it used to be.
So, the CIS 1.5 Benchmark will be in the cfg/cis-1.5 directory. The configuration files inside and their names will stay the same as before - config.yaml, node.yaml, master.yaml

[leodotcloud]

@robertojrojas with 1.5, etcd has been pulled out under it's own section. I guess we would need etcd.yaml along with the existing master.yaml and node.yaml files.

Also, we have master and node as sub commands to the top level CLI (kube-bench), with the introduction of etcd section, we might need a new sub command added as well. Another option would be to pass the role as an argument instead of a sub command and use the name of the role to fetch the corresponding yaml file. With this approach, let's say in future we have a new section (ingress for example) we can easily extend the CLI to accommodate it by adding ingress.yaml file.

[robertojrojas]

@leodotcloud We're still looking into CIS 1.5. I'm not completely sure that's the approach the tool will follow. We'll see. :)

[leodotcloud]

Cool. BTW, one more pointer/suggestion :)

We can reuse the master sub command and pass the controls file using -f. And then have the etcd related controls in it's own file to run the following:

For master: kube-bench master -f master.yaml --outputfile master.json
For etcd: kube-bench master -f etcd.yaml --outputfile etcd.json

[lizrice]

I think I have a proposal that is back-compatible with today's behaviour.

CIS 1.5 has the following sections:

1. Master (well, this is actually called Control Plane Components but this is too close to section 3)
2. Etcd
3. Control Plane
4. Worker
5. Policies

We could refer to these with the following names: master, etcd, controlplane, worker, policies and have the test definitions in corresponding YAML master.yaml, etcd.yaml etc.

Extend the kube-bench sub-commands so that in addition to master and node we accept all these names (where worker and node are equivalent). So,

• kube-bench etcd runs the tests from etcd.yaml
• kube-bench master runs the tests from master.yaml
  etc

As today, if you run kube-bench with no sub-command it will try to run all relevant tests, autodetecting what is appropriate. Currently it looks at whether it's running on a master by looking for the API server executable and run the master tests if so, followed by the worker tests. In CIS-1.5 the etcd section was separated out because etcd might not be running on the same node. We can do a similar check to see if etcd is running simply by looking for the etcd executable and running the etcd tests if so.

The only scored test in section 3 looks at the api-server executable, so it only makes sense to run this on a master node. Section 5 tests could be run anywhere that kubectl is available.

We need to do the version check first so that if we're running the checks from CIS-1.4 we behave as today.

So far so good, but if you don't want to rely on auto-detection you could end up running kube-bench several times. So we can introduce a new sub-command run which takes a --sections parameter:

• kube-bench run --sections etcd, master auto-detects the CIS version and then attempts to run the tests in cfg/<version>/etcd.yaml and cfg/<version>/master.yaml
• kube-bench run --benchmark 1.4 --sections etcd fails because there is no cfg/cis-1.4/etcd.yaml

So overall the logic would be like this:

- Work out what CIS version we are using, as we do today (it is either explicitly specified through --version or --benchmark, or the currently running Kubernetes version is detected and converted to a CIS version)
- If sub-command == run
    - for each section in --sections
        - run the tests from cfg/<version>/<section>.yaml
- Else if other sub-command 
    - run the tests from cfg/<version>/<sub-command>.yaml
- Else (no sub-command)
    - If CIS version <= 1.4
        - if api-server is running, run the master tests
        - run the node tests
    - else (CIS version >= 1.5)
        - if api-server is running, run the master tests and the controlplane tests
        - if etcd is running, run the etcd tests
        - run the node tests and the policies tests

Wdyt?

[ttousai]

@lizrice great proposal!

I want to point out that we should handle cases where some sections are not applicable to particular CIS versions or are renamed.

Some examples:

$ kube-bench etcd --benchmark 1.4
# the example above should fail like kube-bench run --benchmark 1.4 --sections etcd

$ kube-bench worker --benchmark 1.4
# the example above should run kube-bench node --benchmark 1.4 since `worker` is equivalent 
# to `node`

I think the following modification to your pseudocode will do the trick

- Else if other sub-command 
      - run the tests from cfg/<version>/<sub-command>.yaml

should look like:

- Else if other sub-command 
      - If CIS version <= 1.4 and sub-command == worker
            run tests in cfg/<version>/node.yaml
      - run the tests from cfg/<version>/<sub-command>.yaml

[robertojrojas]

@lizrice Overall, I agree with this proposal.

I agree with @ttousai in regards to the translation from worker to node when reading the cfg/<version>/node.yaml That will certainly make compatible with existing CIS benchmarks.

In regards to invalid combinations, kube-bench should display an error in the same manner to the one displayed when both --version and --benchmark are specified at the same time. For example,

$ kube-bench run --benchmark 1.4 --sections etcd
# The specified --sections "etcd" does not apply to the CIS Benchmark 1.4 

Also, I find the word sections to be confusing. Does it make sense if it's called, targets or components instead? For example,

$ kube-bench run --benchmark 1.5 --targets master, etcd

or

$ kube-bench run --benchmark 1.5 --components master, etcd