Add attribute to select profile level

Signed-off-by: Kristian Vlaardingerbroek <[email protected]>

Author: rarenerd

README.md

@@ -3,6 +3,13 @@
 ## Description
 This profile implements the [CIS Kubernetes 1.1.0 Benchmark](https://www.cisecurity.org/benchmark/kubernetes/).
 
+## Attributes
+
+To switch between the CIS profile levels the following attribute can be used:
+
+  * `cis_level: 2`
+    define which profile level to use, accepted values are `1` and `2`.
+
 ## License and Author
 
 * Author:: Kristian Vlaardingerbroek <[email protected]>

controls/1_5_master_node_etcd.rb

@@ -15,6 +15,8 @@
 #
 # author: Kristian Vlaardingerbroek
 
+cis_level = attribute('cis_level', default: '2', description: 'CIS profile level to audit', required: true)
+
 title '1.5 Master Node: etcd'
 
 etcd_regex = Regexp.new(%r{/usr/bin/etcd})
@@ -201,15 +203,17 @@
   end
 end
 
-control 'cis-kubernetes-benchmark-1.5.9' do
-  title 'Ensure that a unique Certificate Authority is used for etcd'
-  desc "Use a different certificate authority for etcd from the one used for Kubernetes.\n\nRationale: etcd is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. Its access should be restricted to specifically designated clients and peers only. Authentication to etcd is based on whether the certificate presented was issued by a trusted certificate authority. There is no checking of certificate attributes such as common name or subject alternative name. As such, if any attackers were able to gain access to any certificate issued by the trusted certificate authority, they would be able to gain full access to the etcd database."
-  impact 0.0
+if cis_level == '2'
+  control 'cis-kubernetes-benchmark-1.5.9' do
+    title 'Ensure that a unique Certificate Authority is used for etcd'
+    desc "Use a different certificate authority for etcd from the one used for Kubernetes.\n\nRationale: etcd is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. Its access should be restricted to specifically designated clients and peers only. Authentication to etcd is based on whether the certificate presented was issued by a trusted certificate authority. There is no checking of certificate attributes such as common name or subject alternative name. As such, if any attackers were able to gain access to any certificate issued by the trusted certificate authority, they would be able to gain full access to the etcd database."
+    impact 0.0
 
-  tag cis: 'kubernetes:1.5.9'
-  tag level: 2
+    tag cis: 'kubernetes:1.5.9'
+    tag level: 2
 
-  describe 'cis-kubernetes-benchmark-1.5.9' do
-    skip 'Review if the CA used for etcd is different from the one used for Kubernetes'
+    describe 'cis-kubernetes-benchmark-1.5.9' do
+      skip 'Review if the CA used for etcd is different from the one used for Kubernetes'
+    end
   end
 end

controls/1_6_master_node_general_security_primitives.rb

@@ -15,6 +15,8 @@
 #
 # author: Kristian Vlaardingerbroek
 
+cis_level = attribute('cis_level', default: '2', description: 'CIS profile level to audit', required: true)
+
 title '1.6 Master Node: General Security Primitives'
 
 control 'cis-kubernetes-benchmark-1.6.1' do
@@ -56,67 +58,69 @@
   end
 end
 
-control 'cis-kubernetes-benchmark-1.6.4' do
-  title 'Create network segmentation using Network Policies'
-  desc "Use network policies to isolate your cluster network.\n\nRationale: Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. A network policy is a specification of how selections of pods are allowed to communicate with each other and other network endpoints. `NetworkPolicy` resources use labels to select pods and define whitelist rules which allow traffic to the selected pods in addition to what is allowed by the isolation policy for a given namespace."
-  impact 0.0
+if cis_level == '2'
+  control 'cis-kubernetes-benchmark-1.6.4' do
+    title 'Create network segmentation using Network Policies'
+    desc "Use network policies to isolate your cluster network.\n\nRationale: Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. A network policy is a specification of how selections of pods are allowed to communicate with each other and other network endpoints. `NetworkPolicy` resources use labels to select pods and define whitelist rules which allow traffic to the selected pods in addition to what is allowed by the isolation policy for a given namespace."
+    impact 0.0
 
-  tag cis: 'kubernetes:1.6.4'
-  tag level: 2
+    tag cis: 'kubernetes:1.6.4'
+    tag level: 2
 
-  describe 'cis-kubernetes-benchmark-1.6.4' do
-    skip 'Review the output of `kubectl get pods --namespace=kube-system` and ensure the `NetworkPolicy` objects are the ones you need.'
+    describe 'cis-kubernetes-benchmark-1.6.4' do
+      skip 'Review the output of `kubectl get pods --namespace=kube-system` and ensure the `NetworkPolicy` objects are the ones you need.'
+    end
   end
-end
 
-control 'cis-kubernetes-benchmark-1.6.5' do
-  title 'Ensure that the seccomp profile is set to docker/default in your pod definitions'
-  desc "Enable `docker/default` seccomp profile in your pod definitions.\n\nRationale: Seccomp (secure computing mode) is used to restrict the set of system calls applications can make, allowing cluster administrators greater control over the security of workloads running in the cluster. Kubernetes disables seccomp profiles by default for historical reasons. You should enable it to ensure that the workloads have restricted actions available within the container."
-  impact 0.0
+  control 'cis-kubernetes-benchmark-1.6.5' do
+    title 'Ensure that the seccomp profile is set to docker/default in your pod definitions'
+    desc "Enable `docker/default` seccomp profile in your pod definitions.\n\nRationale: Seccomp (secure computing mode) is used to restrict the set of system calls applications can make, allowing cluster administrators greater control over the security of workloads running in the cluster. Kubernetes disables seccomp profiles by default for historical reasons. You should enable it to ensure that the workloads have restricted actions available within the container."
+    impact 0.0
 
-  tag cis: 'kubernetes:1.6.5'
-  tag level: 2
+    tag cis: 'kubernetes:1.6.5'
+    tag level: 2
 
-  describe 'cis-kubernetes-benchmark-1.6.5' do
-    skip 'Review all the pod definitions in your cluster and verify that `seccomp` is enabled.'
+    describe 'cis-kubernetes-benchmark-1.6.5' do
+      skip 'Review all the pod definitions in your cluster and verify that `seccomp` is enabled.'
+    end
   end
-end
 
-control 'cis-kubernetes-benchmark-1.6.6' do
-  title 'Apply Security Context to Your Pods and Containers'
-  desc "Apply Security Context to Your Pods and Containers\n\nRationale: A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. When designing your containers and pods, make sure that you configure the security context for your pods, containers, and volumes. A security context is a property defined in the deployment yaml. It controls the security parameters that will be assigned to the pod/container/volume. There are two levels of security context: pod level security context, and container level security context."
-  impact 0.0
+  control 'cis-kubernetes-benchmark-1.6.6' do
+    title 'Apply Security Context to Your Pods and Containers'
+    desc "Apply Security Context to Your Pods and Containers\n\nRationale: A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. When designing your containers and pods, make sure that you configure the security context for your pods, containers, and volumes. A security context is a property defined in the deployment yaml. It controls the security parameters that will be assigned to the pod/container/volume. There are two levels of security context: pod level security context, and container level security context."
+    impact 0.0
 
-  tag cis: 'kubernetes:1.6.6'
-  tag level: 2
+    tag cis: 'kubernetes:1.6.6'
+    tag level: 2
 
-  describe 'cis-kubernetes-benchmark-1.6.6' do
-    skip 'Review the pod definitions in your cluster and verify that you have security contexts defined as appropriate.'
+    describe 'cis-kubernetes-benchmark-1.6.6' do
+      skip 'Review the pod definitions in your cluster and verify that you have security contexts defined as appropriate.'
+    end
   end
-end
 
-control 'cis-kubernetes-benchmark-1.6.7' do
-  title 'Configure Image Provenance using ImagePolicyWebhook admission controller'
-  desc "Configure Image Provenance for your deployment.\n\nRationale: Kubernetes supports plugging in provenance rules to accept or reject the images in your deployments. You could configure such rules to ensure that only approved images are deployed in the cluster."
-  impact 0.0
+  control 'cis-kubernetes-benchmark-1.6.7' do
+    title 'Configure Image Provenance using ImagePolicyWebhook admission controller'
+    desc "Configure Image Provenance for your deployment.\n\nRationale: Kubernetes supports plugging in provenance rules to accept or reject the images in your deployments. You could configure such rules to ensure that only approved images are deployed in the cluster."
+    impact 0.0
 
-  tag cis: 'kubernetes:1.6.7'
-  tag level: 2
+    tag cis: 'kubernetes:1.6.7'
+    tag level: 2
 
-  describe 'cis-kubernetes-benchmark-1.6.7' do
-    skip 'Review the pod definitions in your cluster and verify that image provenance is configured as appropriate.'
+    describe 'cis-kubernetes-benchmark-1.6.7' do
+      skip 'Review the pod definitions in your cluster and verify that image provenance is configured as appropriate.'
+    end
   end
-end
 
-control 'cis-kubernetes-benchmark-1.6.8' do
-  title 'Configure Network policies as appropriate'
-  desc "Configure Network policies as appropriate.\n\nRationale: The Network Policy API is now stable. Network policy, implemented through a network plug-in, allows users to set and enforce rules governing which pods can communicate with each other. You should leverage it as appropriate in your environment."
-  impact 0.0
+  control 'cis-kubernetes-benchmark-1.6.8' do
+    title 'Configure Network policies as appropriate'
+    desc "Configure Network policies as appropriate.\n\nRationale: The Network Policy API is now stable. Network policy, implemented through a network plug-in, allows users to set and enforce rules governing which pods can communicate with each other. You should leverage it as appropriate in your environment."
+    impact 0.0
 
-  tag cis: 'kubernetes:1.6.8'
-  tag level: 2
+    tag cis: 'kubernetes:1.6.8'
+    tag level: 2
 
-  describe 'cis-kubernetes-benchmark-1.6.8' do
-    skip 'Review the network policies enforced and ensure that they are suitable for your requirements.'
+    describe 'cis-kubernetes-benchmark-1.6.8' do
+      skip 'Review the network policies enforced and ensure that they are suitable for your requirements.'
+    end
   end
 end