Sysdig Platform CLI - Compliance
This section explains concepts and notations in the set of the Compliance Benchmarks commands provided.
Usage
The Compliance section contains the following subcommands:
$ sdc-cli compliance --help
Usage: sdc-cli compliance [OPTIONS] COMMAND [ARGS]...
Options:
--help Show this message and exit.
Commands:
add Add a compliance task
del Delete compliance tasks
get Get a compliance task
list List compliance tasks
result Get the result of one compliance run
results Get the list of compliance results
update Update a compliance task
List the compliance benchmarks
To list the compliance benchmarks you can execute:
$ sdc-cli compliance list
id name schedule scope moduleName enabled
320 Docker Benchmark - Everywhere 06:00:00Z/PT12H docker-bench-security True
584 Kubernetes Compliance Check 06:00:00Z/PT12H kube-bench True
567 Linux node checks 06:00:00Z/P1D kubernetes.cluster.name = "prod-aws" linux-bench True
207 Store-frontend CIS Docker bench 06:00:00Z/PT12H kubernetes.namespace.name in ("store-frontend") docker-bench-security True
Add a compliance benchmark
The following options are available to add a compliance benchmark:
sdc-cli compliance add --help
Usage: sdc-cli compliance add [OPTIONS] NAME
NAME: The name of the task e.g. 'Check Docker Compliance'.
Options:
--scope TEXT The agent will only run the task on hosts matching this
scope or on hosts where containers match this scope.
--schedule TEXT The frequency at which this task should run. Expressed as
an ISO 8601 Duration
<https://en.wikipedia.org/wiki/ISO_8601#Durations>
--module TEXT The name of the module that implements this task. Separate
from task name in case you want to use the same module to
run separate tasks with different scopes or schedules. [
'docker-bench-security', 'kube-bench', 'linux-bench' ]
--disabled Disable this task to don't run as defined by its schedule.
--help Show this message and exit.
Selecting linux-bench as module for this benchmark requires agent version >= 9.7.0
For example, if you want to add a Kubernetes benchmark once a week, you can do:
$ sdc-cli compliance add --module kube-bench --schedule PT1W 'Kubernetes benchmark (Weekly)'
id: 909
name: Kubernetes benchmark (Weekly)
schedule: PT1W
moduleName: kube-bench
enabled: True
Delete a compliance benchmark
To remove the previously created compliance benchmark, you can execute:
$ sdc-cli compliance del 909
Success
See results from the compliance benchmarks
We can retrieve the results from the compliance benchmarks in the CLI to review them.
Let’s say we want to check all the failing steps from the last Kubernetes Compliance Check task,
we will execute:
$ sdc-cli compliance results 'Kubernetes Compliance Check' --limit 1
id risk name host mac date tests
1eb18641-d835-4146-ac65-457646f96a16 high Kubernetes Compliance Check 02:62:a0:0b:12:73 2020-09-18 16:06:21.261968 23/65
Now we can list the failing tests with their remediation:
$ sdc-cli compliance result 1eb18641-d835-4146-ac65-447646f96a16 --level fail --remediation
id: 1eb18641-d835-4146-ac65-457646f96a16
risk: high
hostMac: 02:62:a0:0b:12:73
Tests fail/warn/pass: 32/10/23
Completed on: 2020-09-18 16:06:21.261968
1.1. Master Node Configuration Files
1.1.1 fail - Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Scored)
Run the below command (based on the file location on your system) on the master node. For example, chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml
1.1.2 fail - Ensure that the API server pod specification file ownership is set to root:root (Scored)
Run the below command (based on the file location on your system) on the master node. For example, chown root:root /etc/kubernetes/manifests/kube-apiserver.yaml
1.1.3 fail - Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive (Scored)
Run the below command (based on the file location on your system) on the master node. For example, chmod 644 /etc/kubernetes/manifests/kube-controller-manager.yaml
1.1.4 fail - Ensure that the controller manager pod specification file ownership is set to root:root (Scored)
Run the below command (based on the file location on your system) on the master node. For example, chown root:root /etc/kubernetes/manifests/kube-controller-manager.yaml
1.1.5 fail - Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive (Scored)
Run the below command (based on the file location on your system) on the master node. For example, chmod 644 /etc/kubernetes/scheduler.conf
1.1.6 fail - Ensure that the scheduler pod specification file ownership is set to root:root (Scored)
Run the below command (based on the file location on your system) on the master node. For example, chown root:root /etc/kubernetes/scheduler.conf
1.1.7 fail - Ensure that the etcd pod specification file permissions are set to 644 or more restrictive (Scored)
Run the below command (based on the file location on your system) on the master node. For example, chmod 644 /etc/kubernetes/manifests/etcd.yaml
1.1.8 fail - Ensure that the etcd pod specification file ownership is set to root:root (Scored)
Run the below command (based on the file location on your system) on the master node. For example, chown root:root /etc/kubernetes/manifests/etcd.yaml
...