arno/kube-bench
1
0
Fork 0
mirror of https://github.com/aquasecurity/kube-bench.git synced 2024-11-21 15:48:06 +00:00
Code Issues 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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

117
README.md
View File

@ -40,6 +40,31 @@ You can choose to
* install the latest binaries from the [Releases page](https://github.com/aquasecurity/kube-bench/releases),
* compile it from source.
## Running kube-bench
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.13:
```
kube-bench node --version 1.13
```
`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.13`.
`controls` are also organized by distribution under the `cfg` directory for
example `cfg/ocp-3.10`.
### Running inside a container
You can avoid installing kube-bench on the host by running it inside a container using the host PID namespace and mounting the `/etc` and `/var` directories where the configuration and other files are located on the host, so that kube-bench can check their existence and permissions.
@ -136,19 +161,6 @@ go build -o kube-bench .
kube-bench includes a set of test files for Red Hat's OpenShift hardening guide for OCP 3.10 and 3.11. To run this you will need to specify `--version ocp-3.10` when you run the `kube-bench` command (either directly or through YAML). This config version is valid for OCP 3.10 and 3.11.
## Configuration
Kubernetes config and binary file locations and names can vary from installation to installation, so these are configurable in the `cfg/config.yaml` file.
Any settings in the version-specific config file `cfg/<version>/config.yaml` take precedence over settings in the main `cfg/config.yaml` file.
For each type of node (*master*, *node* or *federated*) there is a list of components, and for each component there is a set of binaries (*bins*) and config files (*confs*) that kube-bench will look for (in the order they are listed). If your installation uses a different binary name or config file location for a Kubernetes component, you can add it to `cfg/config.yaml`.
* **bins** - If there is a *bins* list for a component, at least one of these binaries must be running. The tests will consider the parameters for the first binary in the list found to be running.
* **podspecs** - From version 1.2.0 of the benchmark (tests for Kubernetes 1.8), the remediation instructions were updated to assume that the configuration for several kubernetes components is defined in a pod YAML file, and podspec settings define where to look for that configuration.
* **confs** - If one of the listed config files is found, this will be considered for the test. Tests can continue even if no config file is found. If no file is found at any of the listed locations, and a *defaultconf* location is given for the component, the test will give remediation advice using the *defaultconf* location.
* **unitfiles** - From version 1.2.0 of the benchmark (tests for Kubernetes 1.8), the remediation instructions were updated to assume that kubelet configuration is defined in a service file, and this setting defines where to look for that configuration.
## Output
There are three output states
@ -156,37 +168,17 @@ There are three output states
- [WARN] means this test needs further attention, for example it is a test that needs to be run manually
- [INFO] is informational output that needs no further action.
## Configuration
Kubernetes config and binary file locations and names can vary from installation to installation, so these are configurable in the `cfg/config.yaml` file.
Any settings in the version-specific config file `cfg/<version>/config.yaml` take precedence over settings in the main `cfg/config.yaml` file.
You can read more about `kube-bench` configuration in our [documentation](docs/README.md#configuration-and-variables).
## Test config YAML representation
The tests are represented as YAML documents (installed by default into ./cfg).
An example is as listed below:
```
---
controls:
id: 1
text: "Master Checks"
type: "master"
groups:
- id: 1.1
text: "Kube-apiserver"
checks:
- id: 1.1.1
text: "Ensure that the --allow-privileged argument is set (Scored)"
audit: "ps -ef | grep kube-apiserver | grep -v grep"
tests:
bin_op: or
test_items:
- flag: "--allow-privileged"
set: true
- flag: "--some-other-flag"
set: false
remediation: "Edit the /etc/kubernetes/config file on the master node and set the KUBE_ALLOW_PRIV parameter to '--allow-privileged=false'"
scored: true
```
Recommendations (called `checks` in this document) can run on Kubernetes Master, Node or Federated API Servers.
Checks are organized into `groups` which share similar controls (things to check for) and are grouped together in the section of the CIS Kubernetes document.
These groups are further organized under `controls` which can be of the type `master`, `node` or `federated apiserver` to reflect the various Kubernetes node types.
The tests (or "controls") are represented as YAML documents (installed by default into ./cfg). There are different versions of these test YAML files reflecting different versions of the CIS Kubernetes Benchmark. You will find more information about the test file YAML definitions in our [documentation](docs/README.md).
### Omitting checks
@ -202,47 +194,6 @@ If you decide that a recommendation is not appropriate for your environment, you
No tests will be run for this check and the output will be marked [INFO].
## Tests
Tests are the items we actually look for to determine if a check is successful or not. Checks can have multiple tests, which must all be successful for the check to pass.
The syntax for tests:
```
tests:
- flag:
set:
compare:
op:
value:
...
```
You can also define jsonpath and yamlpath tests using the following syntax:
```
tests:
- path:
set:
compare:
op:
value:
...
```
Tests have various `operations` which are used to compare the output of audit commands for success.
These operations are:
- `eq`: tests if the flag value is equal to the compared value.
- `noteq`: tests if the flag value is unequal to the compared value.
- `gt`: tests if the flag value is greater than the compared value.
- `gte`: tests if the flag value is greater than or equal to the compared value.
- `lt`: tests if the flag value is less than the compared value.
- `lte`: tests if the flag value is less than or equal to the compared value.
- `has`: tests if the flag value contains the compared value.
- `nothave`: tests if the flag value 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.
# Roadmap
Going forward we plan to release updates to kube-bench to add support for new releases of the Benchmark, which in turn we can anticipate being made for each new Kubernetes release.

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