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
...