Restructure the CIS and DISA STIG hardening guides

docs/src/_parts/common_hardening.md

@@ -12,6 +12,7 @@ the level of auditing you desire based on the [upstream instructions][].
 Here is a minimal example of such a policy file.
 
 ```
+sudo mkdir -p /var/snap/k8s/common/etc/
 sudo sh -c 'cat >/var/snap/k8s/common/etc/audit-policy.yaml <<EOL
 # Log all requests at the Metadata level.
 apiVersion: audit.k8s.io/v1
@@ -52,6 +53,7 @@ Create a configuration file with the [rate limits][] and place it under
 For example:
 
 ```
+sudo mkdir -p /var/snap/k8s/common/etc/
 sudo sh -c 'cat >/var/snap/k8s/common/etc/eventconfig.yaml <<EOL
 apiVersion: eventratelimit.admission.k8s.io/v1alpha1
 kind: Configuration
@@ -65,6 +67,7 @@ EOL'
 Create an admissions control config file under `/var/k8s/snap/common/etc/` .
 
 ```
+sudo mkdir -p /var/snap/k8s/common/etc/
 sudo sh -c 'cat >/var/snap/k8s/common/etc/admission-control-config-file.yaml <<EOL
 apiVersion: apiserver.config.k8s.io/v1
 kind: AdmissionConfiguration
@@ -204,6 +207,27 @@ Restart `kubelet`.
 sudo systemctl restart snap.k8s.kubelet
 ```
 
+#### Set the maximum time an idle session is permitted prior to disconnect
+
+Idle connections from the Kubelet can be used by unauthorized users to
+perform malicious activity to the nodes, pods, containers, and cluster within
+the Kubernetes Control Plane.
+
+Edit `/var/snap/k8s/common/args/kubelet` and set the argument `--streaming-connection-idle-timeout` to `5m`.
+
+```
+sudo sh -c 'cat >>/var/snap/k8s/common/args/kubelet <<EOL
+--streaming-connection-idle-timeout=5m
+EOL'
+```
+
+Restart `kubelet`.
+
+```
+sudo systemctl restart snap.k8s.kubelet
+```
+
+
 <!-- Links -->
 [upstream instructions]:https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
 [rate limits]:https://kubernetes.io/docs/reference/config-api/apiserver-eventratelimit.v1alpha1

docs/src/snap/howto/security/auditing-steps.md → docs/src/snap/howto/security/cis-assessment.md

@@ -1,31 +1,143 @@
-# {{product}} hardening guide
+# CIS compliance
 
-The {{product}} hardening guide provides actionable steps to enhance the
-security posture of your deployment. These steps are designed to help you align
-with industry-standard frameworks such as CIS and DISA STIG.
-
-{{product}} aligns with many security recommendations by
-default. However, since implementing all security recommendations
+CIS Hardening refers to the process of implementing security configurations that
+align with the benchmarks set by the [Center for Internet Security (CIS)][].
+Out of the box {{product}} complies with the majority of the recommended
+CIS security configurations. Since implementing all security recommendations
 would comes at the expense of compatibility and/or performance we expect
 cluster administrators to follow post deployment hardening steps based on their
-needs.
+needs. This guide covers:
+
+  * Post-deployment hardening steps you could consider for your {{product}}
+  * Using [kube-bench][] to automatically check whether your Kubernetes
+    clusters are configured according to the [CIS Kubernetes Benchmark][]
+  * Manually configuring and auditing each CIS hardening recommendation
+
 
-This how-to has both the recommended minimum hardening steps and also a more
-comprehensive list of manual tests.
+## What you'll need
 
-Please evaluate the implications of each configuration before applying it.
+This guide assumes the following:
 
-## Post-deployment hardening steps
+- You have a bootstrapped {{product}} cluster (see the [getting started] guide)
+- You have root or sudo access to the machine
+- You have reviewed the [post-deployment hardening] guide and have applied the
+  hardening steps that relevant to your use-case 
 
-These steps are common to the hardening process for both CIS and DISA STIG
-compliance.
+
+## Critical post-deployment hardening steps
+
+By completing these steps, you can ensure your cluster achieves does not fail
+any of the CIS hardening recommendations.
 
 ```{include} ../../../_parts/common_hardening.md
 ```
 
-If you would also like to apply further DISA STIG recommendations please see [additional DISA STIG-specific steps].
+## Assess CIS hardening with kube-bench
+
+Download the latest [kube-bench release][] on your Kubernetes nodes. Make sure
+to select the appropriate binary version.
+
+For example, to download the Linux binary, use the following command. Replace
+`KB` by the version listed in the releases page.
+
+```
+KB=8.0
+mkdir kube-bench
+cd kube-bench
+curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.$KB/kube-bench_0.$KB\_linux_amd64.tar.gz -o kube-bench_0.$KB\_linux_amd64.tar.gz
+```
+
+Extract the downloaded tarball and move the binary to a directory in your PATH:
+
+```
+tar -xvf kube-bench_0.$KB\_linux_amd64.tar.gz
+sudo mv kube-bench /usr/local/bin/
+```
+
+Verify kube-bench installation.
+
+```
+kube-bench version
+```
+
+The output should list the version installed.
+
+Install `kubectl` and configure it to interact with the cluster.
+
+```{warning}
+This will override your ~/.kube/config if you already have kubectl installed in your cluster.
+```
+
+```
+sudo snap install kubectl --classic
+mkdir ~/.kube/
+sudo k8s kubectl config view --raw > ~/.kube/config
+export KUBECONFIG=~/.kube/config
+```
+
+Get CIS hardening checks applicable for {{product}}:
+
+```
+git clone -b ck8s-dqlite https://github.com/canonical/kube-bench.git kube-bench-ck8s-cfg
+```
+
+Test-run kube-bench against {{product}}:
+
+```
+sudo -E kube-bench --version ck8s-cis-1.24 --config-dir ./kube-bench-ck8s-cfg/cfg/ --config ./kube-bench-ck8s-cfg/cfg/config.yaml
+```
+
+Review the warnings detected and address any failing checks you see fit.
+
+```
+[INFO] 1 Control Plane Security Configuration
+...
+[PASS] 1.1.7 Ensure that the dqlite configuration file permissions are set to 644 or more restrictive (Automated)
+[PASS] 1.1.8 Ensure that the dqlite configuration file ownership is set to root:root (Automated)
+...
+[PASS] 1.1.11 Ensure that the dqlite data directory permissions are set to 700 or more restrictive (Automated)
+[PASS] 1.1.12 Ensure that the dqlite data directory ownership is set to root:root (Automated)
+...
+== Summary master ==
+55 checks PASS
+0 checks FAIL
+4 checks WARN
+0 checks INFO
+
+[INFO] 3 Control Plane Configuration
+...
+== Summary controlplane ==
+1 checks PASS
+0 checks FAIL
+2 checks WARN
+0 checks INFO
+
+[INFO] 4 Worker Node Security Configuration
+...
+== Summary node ==
+23 checks PASS
+0 checks FAIL
+0 checks WARN
+0 checks INFO
+
+[INFO] 5 Kubernetes Policies
+...
+== Summary policies ==
+0 checks PASS
+0 checks FAIL
+30 checks WARN
+0 checks INFO
+
+== Summary total ==
+79 checks PASS
+0 checks FAIL
+36 checks WARN
+0 checks INFO
+
+```
+
 
-## Comprehensive Hardening Checklist
+## Manually audit CIS hardening recommendations
 
 In what follows we iterate over all hardening recommendations
 and, when possible, provide information on how to comply with each
@@ -3223,7 +3335,9 @@ specific namespace.
 
 
 <!-- Links -->
-[Post-Deployment Configuration Steps section]:#post-deployment-configuration-steps
-[upstream instructions]:https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
-[rate limits]:https://kubernetes.io/docs/reference/config-api/apiserver-eventratelimit.v1alpha1
-[additional DISA STIG-specific steps]: disa-stig-hardening#disa-stig-specific-steps
+[Center for Internet Security (CIS)]:https://www.cisecurity.org/
+[kube-bench]:https://aquasecurity.github.io/kube-bench/v0.6.15/
+[CIS Kubernetes Benchmark]:https://www.cisecurity.org/benchmark/kubernetes
+[getting started]: ../../tutorial/getting-started
+[kube-bench release]: https://github.com/aquasecurity/kube-bench/releases
+[post-deployment hardening]: hardening.md