mirror of
https://github.com/aquasecurity/kube-bench.git
synced 2024-11-24 17:08:14 +00:00
Fixed some typos (#446)
* 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
Simarpreet Singh
parent
7ca438b618
commit
8e4da53006
32
README.md
32
README.md
@ -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,15 +253,15 @@ 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)
|
||||
|
||||
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` )
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user