mirror of
https://github.com/aquasecurity/kube-bench.git
synced 2024-11-25 17:38:21 +00:00
Fix supported targets for EKS benchmark (#648)
* Fix supported targets for EKS benchmark * docs: heading at wrong level in README * docs: remove duplicate TOC heading * Fix invalid argument for gem install Co-authored-by: Liz Rice <liz@lizrice.com>
This commit is contained in:
Matthieu ANTOINE
GitHub
parent
2a325bd60d
commit
ea4eaa6fd5
@ -11,7 +11,7 @@ before_install:
|
||||
- sudo apt-get -qq update
|
||||
- sudo apt-get install -y rpm
|
||||
- pip install --user yamllint==1.18.0
|
||||
- gem install --no-ri --no-rdoc fpm
|
||||
- gem install --no-document fpm
|
||||
- go get -t -v ./...
|
||||
|
||||
script:
|
||||
|
||||
93
README.md
93
README.md
@ -8,13 +8,13 @@
|
||||
[cov]: https://codecov.io/github/aquasecurity/kube-bench
|
||||
<img src="images/kube-bench.png" width="200" alt="kube-bench logo">
|
||||
|
||||
kube-bench is a Go application that checks whether Kubernetes is deployed securely by running the checks documented in the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/).
|
||||
kube-bench is a Go application that checks whether Kubernetes is deployed securely by running the checks documented in the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/).
|
||||
|
||||
Tests are configured with YAML files, making this tool easy to update as test specifications evolve.
|
||||
|
||||
### Please Note
|
||||
### Please Note
|
||||
|
||||
1. kube-bench implements the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) as closely as possible. Please raise issues here if kube-bench is not correctly implementing the test as described in the Benchmark. To report issues in the Benchmark itself (for example, tests that you believe are inappropriate), please join the [CIS community](https://cisecurity.org).
|
||||
1. kube-bench implements the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) as closely as possible. Please raise issues here if kube-bench is not correctly implementing the test as described in the Benchmark. To report issues in the Benchmark itself (for example, tests that you believe are inappropriate), please join the [CIS community](https://cisecurity.org).
|
||||
|
||||
1. There is not a one-to-one mapping between releases of Kubernetes and releases of the CIS benchmark. See [CIS Kubernetes Benchmark support](#cis-kubernetes-benchmark-support) to see which releases of Kubernetes are covered by different releases of the benchmark.
|
||||
|
||||
@ -26,32 +26,33 @@ Tests are configured with YAML files, making this tool easy to update as test sp
|
||||
Table of Contents
|
||||
=================
|
||||
|
||||
* [CIS Kubernetes Benchmark support](#cis-kubernetes-benchmark-support)
|
||||
* [Installation](#installation)
|
||||
* [Running kube-bench](#running-kube-bench)
|
||||
* [Running inside a container](#running-inside-a-container)
|
||||
* [Running in a kubernetes cluster](#running-in-a-kubernetes-cluster)
|
||||
* [Running in an Azure Kubernetes Service(AKS) cluster](#running-in-an-aks-cluster)
|
||||
* [Running in an EKS cluster](#running-in-an-eks-cluster)
|
||||
* [Installing from a container](#installing-from-a-container)
|
||||
* [Installing from sources](#installing-from-sources)
|
||||
* [Running on OpenShift](#running-on-openshift)
|
||||
* [Output](#output)
|
||||
* [Configuration](#configuration)
|
||||
* [Troubleshooting](#troubleshooting)
|
||||
* [Test config YAML representation](#test-config-yaml-representation)
|
||||
* [Omitting checks](#omitting-checks)
|
||||
* [Roadmap](#roadmap)
|
||||
* [Testing locally with kind](#testing-locally-with-kind)
|
||||
* [Contributing](#contributing)
|
||||
* [Bugs](#bugs)
|
||||
* [Features](#features)
|
||||
* [Pull Requests](#pull-requests)
|
||||
- [CIS Kubernetes Benchmark support](#cis-kubernetes-benchmark-support)
|
||||
- [Installation](#installation)
|
||||
- [Running kube-bench](#running-kube-bench)
|
||||
- [Running inside a container](#running-inside-a-container)
|
||||
- [Running in a Kubernetes cluster](#running-in-a-kubernetes-cluster)
|
||||
- [Running in an AKS cluster](#running-in-an-aks-cluster)
|
||||
- [Running in an EKS cluster](#running-in-an-eks-cluster)
|
||||
- [Installing from a container](#installing-from-a-container)
|
||||
- [Installing from sources](#installing-from-sources)
|
||||
- [Running on OpenShift](#running-on-openshift)
|
||||
- [Running in an GKE cluster](#running-in-an-gke-cluster)
|
||||
- [Output](#output)
|
||||
- [Configuration](#configuration)
|
||||
- [Troubleshooting](#troubleshooting)
|
||||
- [Test config YAML representation](#test-config-yaml-representation)
|
||||
- [Omitting checks](#omitting-checks)
|
||||
- [Roadmap](#roadmap)
|
||||
- [Testing locally with kind](#testing-locally-with-kind)
|
||||
- [Contributing](#contributing)
|
||||
- [Bugs](#bugs)
|
||||
- [Features](#features)
|
||||
- [Pull Requests](#pull-requests)
|
||||
|
||||
|
||||
|
||||
## CIS Kubernetes Benchmark support
|
||||
|
||||
kube-bench supports the tests for Kubernetes as defined in the [CIS Kubernetes Benchmarks](https://www.cisecurity.org/benchmark/kubernetes/).
|
||||
kube-bench supports the tests for Kubernetes as defined in the [CIS Kubernetes Benchmarks](https://www.cisecurity.org/benchmark/kubernetes/).
|
||||
|
||||
| CIS Kubernetes Benchmark | kube-bench config | Kubernetes versions |
|
||||
|---|---|---|
|
||||
@ -60,9 +61,9 @@ kube-bench supports the tests for Kubernetes as defined in the [CIS Kubernetes B
|
||||
| [1.5.0](https://workbench.cisecurity.org/benchmarks/1370) | cis-1.5 | 1.15- |
|
||||
| [GKE 1.0.0](https://workbench.cisecurity.org/benchmarks/4536) | gke-1.0 | GKE |
|
||||
| [EKS 1.0.0](https://workbench.cisecurity.org/benchmarks/5190) | eks-1.0 | EKS |
|
||||
| Red Hat OpenShift hardening guide | rh-0.7 | OCP 3.10-3.11 |
|
||||
| Red Hat OpenShift hardening guide | rh-0.7 | OCP 3.10-3.11 |
|
||||
|
||||
By default, kube-bench will determine the test set to run based on the Kubernetes version running on the machine, but please note that kube-bench does not automatically detect OpenShift and GKE - see the section below on [Running kube-bench](https://github.com/aquasecurity/kube-bench#running-kube-bench).
|
||||
By default, kube-bench will determine the test set to run based on the Kubernetes version running on the machine, but please note that kube-bench does not automatically detect OpenShift and GKE - see the section below on [Running kube-bench](https://github.com/aquasecurity/kube-bench#running-kube-bench).
|
||||
|
||||
## Installation
|
||||
|
||||
@ -79,7 +80,7 @@ If you run kube-bench directly from the command line you may need to be root / s
|
||||
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.
|
||||
`--version` flag on the command line.
|
||||
|
||||
|
||||
The Kubernetes version can also be set with the `KUBE_BENCH_VERSION` environment variable.
|
||||
@ -122,7 +123,7 @@ The following table shows the valid targets based on the CIS Benchmark version.
|
||||
| cis-1.4| master, node |
|
||||
| cis-1.5| master, controlplane, node, etcd, policies |
|
||||
| gke-1.0| master, controlplane, node, etcd, policies, managedservices |
|
||||
| eks-1.0| node, policies, managedservices |
|
||||
| eks-1.0| controlplane, node, policies, managedservices |
|
||||
|
||||
If no targets are specified, `kube-bench` will determine the appropriate targets based on the CIS Benchmark version.
|
||||
|
||||
@ -133,7 +134,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
|
||||
@ -142,7 +143,7 @@ docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -t aquasec/kube-bench:late
|
||||
> Note: the tests require either the kubelet or kubectl binary in the path in order to auto-detect the Kubernetes version. You can pass `-v $(which kubectl):/usr/local/mount-from-host/bin/kubectl` to resolve this. You will also need to pass in kubeconfig credentials. For example:
|
||||
|
||||
```
|
||||
docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl -v ~/.kube:/.kube -e KUBECONFIG=/.kube/config -t aquasec/kube-bench:latest [master|node]
|
||||
docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl -v ~/.kube:/.kube -e KUBECONFIG=/.kube/config -t aquasec/kube-bench:latest [master|node]
|
||||
```
|
||||
|
||||
You can use your own configs by mounting them over the default ones in `/opt/kube-bench/cfg/`
|
||||
@ -191,10 +192,10 @@ The default labels applied to master nodes has changed since Kubernetes 1.11, so
|
||||
|
||||
1. Create an AKS cluster(e.g. 1.13.7) with RBAC enabled, otherwise there would be 4 failures
|
||||
|
||||
1. Use the [kubectl-enter plugin] (https://github.com/kvaps/kubectl-enter) to shell into a node
|
||||
1. Use the [kubectl-enter plugin] (https://github.com/kvaps/kubectl-enter) to shell into a node
|
||||
`
|
||||
kubectl-enter {node-name}
|
||||
`
|
||||
`
|
||||
or ssh to one agent node
|
||||
could open nsg 22 port and assign a public ip for one agent node (only for testing purpose)
|
||||
|
||||
@ -203,7 +204,7 @@ could open nsg 22 port and assign a public ip for one agent node (only for testi
|
||||
docker run --rm -v `pwd`:/host aquasec/kube-bench:latest install
|
||||
./kube-bench node
|
||||
```
|
||||
kube-bench cannot be run on AKS master nodes
|
||||
kube-bench cannot be run on AKS master nodes
|
||||
|
||||
### Running in an EKS cluster
|
||||
|
||||
@ -257,7 +258,7 @@ go build -o kube-bench .
|
||||
./kube-bench
|
||||
```
|
||||
|
||||
## Running on OpenShift
|
||||
### Running on OpenShift
|
||||
|
||||
| OpenShift Hardening Guide | kube-bench config |
|
||||
|---|---|
|
||||
@ -266,7 +267,7 @@ 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 `--benchmark rh-07`, or `--version ocp-3.10` or `--version ocp-3.11`
|
||||
|
||||
when you run the `kube-bench` command (either directly or through YAML).
|
||||
when you run the `kube-bench` command (either directly or through YAML).
|
||||
|
||||
### Running in an GKE cluster
|
||||
| CIS Benchmark | Targets |
|
||||
@ -304,9 +305,9 @@ You can read more about `kube-bench` configuration in our [documentation](docs/R
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Running `kube-bench` with the `-v 3 --logtostderr` parameters will generate debug logs that can be very helpful for debugging problems.
|
||||
Running `kube-bench` with the `-v 3 --logtostderr` parameters will generate debug logs that can be very helpful for debugging problems.
|
||||
|
||||
If you are using one of the example `job*.yaml` files, you will need to edit the `command` field, for example `["kube-bench", "-v", "3", "--logtostderr"]`. Once the job has run, the logs can be retrieved using `kubectl logs` on the job's pod.
|
||||
If you are using one of the example `job*.yaml` files, you will need to edit the `command` field, for example `["kube-bench", "-v", "3", "--logtostderr"]`. Once the job has run, the logs can be retrieved using `kubectl logs` on the job's pod.
|
||||
|
||||
## Test config YAML representation
|
||||
|
||||
@ -314,7 +315,7 @@ The tests (or "controls") are represented as YAML documents (installed by defaul
|
||||
|
||||
### Omitting checks
|
||||
|
||||
If you decide that a recommendation is not appropriate for your environment, you can choose to omit it by editing the test YAML file to give it the check type `skip` as in this example:
|
||||
If you decide that a recommendation is not appropriate for your environment, you can choose to omit it by editing the test YAML file to give it the check type `skip` as in this example:
|
||||
|
||||
```yaml
|
||||
checks:
|
||||
@ -328,7 +329,7 @@ No tests will be run for this check and the output will be marked [INFO].
|
||||
|
||||
## Roadmap
|
||||
|
||||
Going forward we plan to release updates to kube-bench to add support for new releases of the CIS Benchmark. Note that these are not released as frequently as Kubernetes releases.
|
||||
Going forward we plan to release updates to kube-bench to add support for new releases of the CIS Benchmark. Note that these are not released as frequently as Kubernetes releases.
|
||||
|
||||
We welcome PRs and issue reports.
|
||||
|
||||
@ -368,12 +369,12 @@ We also use the GitHub issue tracker to track feature requests. If you have an i
|
||||
- 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
|
||||
### Pull Requests
|
||||
|
||||
We welcome pull requests!
|
||||
We welcome pull requests!
|
||||
|
||||
- Your PR is more likely to be accepted if it focuses on just one change.
|
||||
- Please include a comment with the results before and after your change.
|
||||
- Your PR is more likely to be accepted if it includes tests. (We have not historically been very strict about tests, but we would like to improve this!).
|
||||
- You're welcome to submit a draft PR if you would like early feedback on an idea or an approach.
|
||||
- Please include a comment with the results before and after your change.
|
||||
- Your PR is more likely to be accepted if it includes tests. (We have not historically been very strict about tests, but we would like to improve this!).
|
||||
- You're welcome to submit a draft PR if you would like early feedback on an idea or an approach.
|
||||
- Happy coding!
|
||||
|
||||
@ -422,6 +422,7 @@ var benchmarkVersionToTargetsMap = map[string][]string{
|
||||
"cis-1.4": []string{string(check.MASTER), string(check.NODE)},
|
||||
"cis-1.5": []string{string(check.MASTER), string(check.NODE), string(check.CONTROLPLANE), string(check.ETCD), string(check.POLICIES)},
|
||||
"gke-1.0": []string{string(check.MASTER), string(check.NODE), string(check.CONTROLPLANE), string(check.ETCD), string(check.POLICIES), string(check.MANAGEDSERVICES)},
|
||||
"eks-1.0": []string{string(check.NODE), string(check.CONTROLPLANE), string(check.POLICIES), string(check.MANAGEDSERVICES)},
|
||||
}
|
||||
|
||||
// validTargets helps determine if the targets
|
||||
|
||||
@ -399,6 +399,12 @@ func TestValidTargets(t *testing.T) {
|
||||
targets: []string{"master", "node", "controlplane", "etcd", "policies", "managedservices"},
|
||||
expected: true,
|
||||
},
|
||||
{
|
||||
name: "eks-1.0 valid",
|
||||
benchmark: "eks-1.0",
|
||||
targets: []string{"node", "policies", "controlplane", "managedservices"},
|
||||
expected: true,
|
||||
},
|
||||
}
|
||||
|
||||
for _, c := range cases {
|
||||
|
||||
Loading…
Reference in New Issue
Block a user