github/kube-bench
1
0
Fork 0
mirror of https://github.com/aquasecurity/kube-bench.git synced 2026-02-14 18:10:00 +00:00
Code Issues Packages Projects Releases Wiki Activity

Remove duplicate documentation. (#373)

Browse Source 
* Remove duplicate documentation.

* Add test configuration header back in main README.

* Add missing regex operator in docs/README.

* Fix incorrect description of configuration options bins, confs etc.

* Move description of version auto-detection to main README.

* Use 1.13 in examples since cfg/1.12 doesn't exist

* Remove duplicate sentence about regex

This sentence is now in the docs/README

* Add link to the docs for test YAML definitions
This commit is contained in:
Abubakr-Sadik Nii Nai Davis
2019-08-07 10:43:51 +00:00
committed by Liz Rice
parent b8a463f051
commit 2e27d681f7
2 changed files with 47 additions and 123 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
docs/README.md
View File

@@ -4,30 +4,11 @@
representation of the CIS Kubernetes Benchmark checks. There is a
`controls` file per kubernetes version and node type.
kube-bench automatically selects which `controls` to use based on the detected
node type and the version of kubernetes a cluster is running. This behaviour
can be overridden by specifying the `master` or `node` subcommand and the
`--version` flag on the command line.
For example:
run kube-bench against a master with version auto-detection:
```
kube-bench master
```
or run kube-bench against a node with the node `controls` for kubernetes
version 1.12:
```
kube-bench node --version 1.12
```
`controls` for the various versions of kubernetes can be found in directories
with same name as the kubernetes versions under `cfg/`, for example `cfg/1.12`.
`controls` are also organized by distribution under the `cfg` directory for
example `cfg/ocp-3.10`.
## Controls
`controls` is a YAML document that contains checks that must be run against a
@@ -248,6 +229,9 @@ The `op` (operations) currently supported in `kube-bench` are:
- `lte`: tests if the keyword is less than or equal to the compared value.
- `has`: tests if the keyword contains the compared value.
- `nothave`: tests if the keyword does not contain the compared value.
- `regex`: tests if the flag value matches the compared value regular expression.
When defining regular expressions in YAML it is generally easier to wrap them in
single quotes, for example `'^[abc]$'`, to avoid issues with string escaping.
## Configuration and Variables
@@ -291,12 +275,11 @@ Every node type has a subsection that specifies the main configurations items.
Each component has the following entries:
- `bins`: A list of candidate binaries for a component. `kube-bench` checks this
list and selects the first binary that is running on the node, if none is
running, `kube-bench` terminates.
list and selects the first binary that is running on the node.
If `defaultbin` is specified, `kube-bench` ignores the `bins` list (if it is
specified) and verifies the binary specified with `defaultbin` is running on
the node. `kube-bench` terminates if this binary is not running.
if none of the binaries in `bins` list is running, `kube-bench` checks if the
binary specified by `defaultbin` is running and terminates if none of the
binaries in both `bins` and `defaultbin` is running.
The selected binary for a component can be referenced in `controls` using a
variable in the form `$<component>bin`. In the example below, we reference
@@ -311,12 +294,9 @@ Every node type has a subsection that specifies the main configurations items.
```
- `confs`: A list of candidate configuration files for a component. `kube-bench`
checks this list and selects the first config fille that is found on the node,
if none of the config files exists `kube-bench` terminates.
If `defaultconf`is specified for a component, `kube-bench` ignores the `confs`
list (if it is specified) and verifies the config specified by `defaultconf`
exists on the node. `kube-bench` terminates if this file does not exist.
checks this list and selects the first config file that is found on the node,
if none of the config files exists, `kube-bench` defaults conf to the value
of `defaultconf`.
The selected config for a component can be referenced in `controls` using a
variable in the form `$<component>conf`. In the example below we reference the
@@ -333,11 +313,7 @@ Every node type has a subsection that specifies the main configurations items.
- `svcs`: A list of candidates unitfiles for a component. `kube-bench` checks this
list and selects the first unitfile that is found on the node, if none of the
unitfiles exists `kube-bench` terminates.
If `defaultsvc`is specified for a component, `kube-bench` ignores the `svcs`
list (if it is specified) and verifies the unitfile specified by `defaultsvc`
exists on the node. `kube-bench` terminates if this file does not exist.
unitfiles exists, `kube-bench` defaults unitfile to the value of `defaultsvc`.
The selected unitfile for a component can be referenced in `controls` via a
variable in the form `$<component>svc`. In the example below, the selected
@@ -359,11 +335,8 @@ Every node type has a subsection that specifies the main configurations items.
- `kubeconfig`: A list of candidate kubeconfig files for a component. `kube-bench`
checks this list and selects the first file that is found on the node, if none
of the files exists `kube-bench` terminates.
If `defaultkubeconfig` is specified for a component, `kube-bench` ignores the
`kubeconfig` list (if it is specified) and verifies the kubeconfig file exists on
the node. `kube-bench` terminates if this file does not exist.
of the files exists, `kube-bench` defaults kubeconfig to the value of
`defaultkubeconfig`.
The selected kubeconfig for a component can be referenced in `controls` with
a variable in the form `$<component>kubeconfig`. In the example below, the