arno/kube-bench
1
0
Fork 0
mirror of https://github.com/aquasecurity/kube-bench.git synced 2024-11-24 08:58:11 +00:00
Code Issues Releases Wiki Activity

Fixed some typos (#446)

Browse Source 
* Fixed some typos

* Fixed some typos

* Fixed typo and capitalization of Kubernetes

* Update README.md

Co-Authored-By: Liz Rice <liz@lizrice.com>

* Update README.md

Co-Authored-By: Liz Rice <liz@lizrice.com>

* Update docs/README.md

Co-Authored-By: Liz Rice <liz@lizrice.com>

* Update docs/README.md

Co-Authored-By: Liz Rice <liz@lizrice.com>

* Update README.md

Co-Authored-By: Liz Rice <liz@lizrice.com>

* Update docs/README.md

Co-Authored-By: Liz Rice <liz@lizrice.com>

* docs: trivial, reinstate capital K

* docs: trivial, reinstate backticks

* docs: trivial, reinstate "in order" for clarity

* docs: trivial, reinstate capital K
This commit is contained in:
Soumyadeep Sinha 2019-11-06 04:29:29 +05:30 committed by Simarpreet Singh
parent 7ca438b618
commit 8e4da53006
2 changed files with 24 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
README.md
View File

@ -50,7 +50,7 @@ kube-bench supports the tests for Kubernetes as defined in the CIS Benchmarks 1.
| 1.4.1| cis-1.4 | 1.13- |
By default kube-bench will determine the test set to run based on the Kubernetes version running on the machine.
By default, kube-bench will determine the test set to run based on the Kubernetes version running on the machine.
There is also preliminary support for Red Hat's OpenShift Hardening Guide for 3.10 and 3.11. Please note that kube-bench does not automatically detect OpenShift - see below.
@ -66,13 +66,14 @@ You can choose to
## Running kube-bench
If you run kube-bench directly from the command line you may need to be root/sudo in order to have access to all the config files.
If you run kube-bench directly from the command line you may need to be root / sudo to have access to all the config files.
kube-bench automatically selects which `controls` to use based on the detected
node type and the version of Kubernetes a cluster is running. This behavior
can be overridden by specifying the `master` or `node` subcommand and the
`--version` flag on the command line.
The Kubernetes version can also be set with the `KUBE_BENCH_VERSION` environment variable.
The value of `--version` takes precedence over the value of `KUBE_BENCH_VERSION`.
@ -82,22 +83,15 @@ 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:
Or run kube-bench against a worker node using the tests for Kubernetes version 1.13:
```
kube-bench node --version 1.13
```
`kube-bench` will map the `--version` to the corresponding CIS Benchmark version as indicated by the version mapping table above.
`kube-bench` will map the `--version` to the corresponding CIS Benchmark version as indicated by the mapping table above. For example, if you specify `--version 1.13`, this is mapped to CIS Benchmark version `cis-1.14`.
For example, if you specify:
```
kube-bench node --version 1.13
```
`kube-bench` will map the `1.13` to CIS Bechmark version `cis-1.14`
Also, you can specify `--benchmark` to run a specific CIS Benchmark version:
Alternatively, you can specify `--benchmark` to run a specific CIS Benchmark version:
```
kube-bench node --benchmark cis-1.4
@ -110,7 +104,7 @@ with same name as the CIS Benchmark versions under `cfg/`, for example `cfg/cis-
### 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.
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.
```
docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -t aquasec/kube-bench:latest [master|node] --version 1.13
@ -196,7 +190,7 @@ go build -o kube-bench .
# See all supported options
./kube-bench --help
# Run the all checks
# Run all checks
./kube-bench
```
@ -259,17 +253,17 @@ We welcome PRs and issue reports.
## Testing locally with kind
Our makefile contains targets to test your current version of kube-bench inside a [Kind](https://kind.sigs.k8s.io/) cluster. This can be very handy if you don't want to run a real Kubernetes cluster for development purpose.
Our makefile contains targets to test your current version of kube-bench inside a [Kind](https://kind.sigs.k8s.io/) cluster. This can be very handy if you don't want to run a real Kubernetes cluster for development purposes.
First you'll need to create the cluster using `make kind-test-cluster` this will create a new cluster if it cannot be found on your machine. By default the cluster is named `kube-bench` but you can change the name by using the environment variable `KIND_PROFILE`.
First, you'll need to create the cluster using `make kind-test-cluster` this will create a new cluster if it cannot be found on your machine. By default, the cluster is named `kube-bench` but you can change the name by using the environment variable `KIND_PROFILE`.
*If kind cannot be found on your system the target will try to install it using `go get`*
Next you'll have to build the kube-bench docker image using `make build-docker`, then we will be able to push the docker image to the cluster using `make kind-push`.
Next, you'll have to build the kube-bench docker image using `make build-docker`, then we will be able to push the docker image to the cluster using `make kind-push`.
Finally we can use the `make kind-run` target to run the current version of kube-bench in the cluster and follow the logs of pods created. (Ctrl+C to exit)
Finally, we can use the `make kind-run` target to run the current version of kube-bench in the cluster and follow the logs of pods created. (Ctrl+C to exit)
Everytime you want to test a change, you'll need to rebuild the docker image and push it to cluster before running it again. ( `make build-docker kind-push kind-run` )
Every time you want to test a change, you'll need to rebuild the docker image and push it to cluster before running it again. ( `make build-docker kind-push kind-run` )
## Contributing
@ -290,7 +284,7 @@ We also use the GitHub issue tracker to track feature requests. If you have an i
- Open a [new issue](https://github.com/aquasecurity/kube-bench/issues/new).
- Remember users might be searching for your issue in the future, so please give it a meaningful title to helps others.
- Clearly define the use case, using concrete examples. For example: I type `this` and kube-bench does `that`.
- Clearly define the use case, using concrete examples. For example, I type `this` and kube-bench does `that`.
- If you would like to include a technical design for your feature please feel free to do so.
### Pull Requests

29
docs/README.md
View File

@ -1,13 +1,7 @@
# Test and config files
`kube-bench` runs checks specified in `controls` files that are a YAML
representation of the CIS Kubernetes Benchmark checks. There is a
`controls` file per Kubernetes version and node type.
`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`.
representation of the CIS Kubernetes Benchmark checks (or other distribution-specific hardening guides).
## Controls
@ -67,10 +61,10 @@ for `type` are `master` and `node`.
## Groups
`groups` is list of subgroups which test the various Kubernetes components
`groups` is a list of subgroups that test the various Kubernetes components
that run on the node type specified in the `controls`.
For example one subgroup checks parameters passed to the apiserver binary, while
For example, one subgroup checks parameters passed to the API server binary, while
another subgroup checks parameters passed to the controller-manager binary.
```yml
@ -110,8 +104,7 @@ command line, with the flag `--group` or `-g`.
## Check
The CIS Kubernetes Benchmark recommends configurations to harden Kubernetes
components. These recommendations are usually configuration options, and can be
The CIS Kubernetes Benchmark recommends configurations to harden Kubernetes components. These recommendations are usually configuration options and can be
specified by flags to Kubernetes binaries, or in configuration files.
The Benchmark also provides commands to audit a Kubernetes installation, identify
@ -149,7 +142,7 @@ The `audit` field specifies the command to run for a check. The output of this
command is then evaluated for conformance with the CIS Kubernetes Benchmark
recommendation.
The audit is evaluated against a criteria specified by the `tests`
The audit is evaluated against criteria specified by the `tests`
object. `tests` contain `bin_op` and `test_items`.
`test_items` specify the criteria(s) the `audit` command's output should meet to
@ -160,7 +153,7 @@ values expected by the CIS Kubernetes Benchmark.
There are two ways to extract keywords from the output of the `audit` command,
`flag` and `path`.
`flag` is used when the keyword is a command line flag. The associated `audit`
`flag` is used when the keyword is a command-line flag. The associated `audit`
command is usually a `ps` command and a `grep` for the binary whose flag we are
checking:
@ -205,8 +198,7 @@ tests:
set: true
```
`set` checks if a keyword is present in the output of the audit command or in
a config file. The possible values for `set` are true and false.
`set` checks if a keyword is present in the output of the audit command or a config file. The possible values for `set` are true and false.
If `set` is true, the check passes only if the keyword is present in the output
of the audit command, or config file. If `set` is false, the check passes only
@ -242,7 +234,7 @@ referenced in a `controls` file via variables.
The `cfg/config.yaml` file is a global configuration file. Configuration files
can be created for specific Kubernetes versions (distributions). Values in the
version specific config overwrite similar values in `cfg/config.yaml`.
version-specific config overwrite similar values in `cfg/config.yaml`.
For example, the kube-apiserver in Red Hat OCP distribution is run as
`hypershift openshift-kube-apiserver` instead of the default `kube-apiserver`.
@ -298,7 +290,7 @@ Every node type has a subsection that specifies the main configuration items.
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
variable in the form `$<component>conf`. In the example below, we reference the
selected API server config file with the variable `$apiserverconf` in an `audit`
command.
@ -336,8 +328,7 @@ Every node type has a subsection that specifies the main configuration items.
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
The selected kubeconfig for a component can be referenced in `controls` with a variable in the form `$<component>kubeconfig`. In the example below, the
selected kubelet kubeconfig is referenced with `$kubeletkubeconfig` in the
`audit` command.