Add ansible to rule S6868

rules/S6868/ansible/rule.adoc

@@ -1,44 +1,71 @@
-FIXME: add a description
-
-// If you want to factorize the description uncomment the following line and create the file.
-//include::../description.adoc[]
-
-== Why is this an issue?
-
-FIXME: remove the unused optional headers (that are commented out)
-
-//=== What is the potential impact?
+include::../kubernetes/description.adoc[]
 
 == How to fix it
-//== How to fix it in FRAMEWORK NAME
 
 === Code examples
 
 ==== Noncompliant code example
 
 [source,yaml,diff-id=1,diff-type=noncompliant]
 ----
-FIXME
+- name: Noncompliant example task
+  kubernetes.core.k8s:
+    state: present
+    definition:
+      apiVersion: rbac.authorization.k8s.io/v1
+      kind: Role
+      metadata:
+        namespace: default
+        name: example-role
+      rules:
+        - apiGroups: [""]
+          resources: ["pods"]
+          verbs: ["get"]
+        - apiGroups: [""]
+          resources: ["pods/exec"] # Noncompliant
+          verbs: ["create"]
 ----
 
 ==== Compliant solution
 
 [source,yaml,diff-id=1,diff-type=compliant]
 ----
-FIXME
+- name: Compliant example Task
+  kubernetes.core.k8s:
+    state: present
+    definition:
+      apiVersion: rbac.authorization.k8s.io/v1
+      kind: Role
+      metadata:
+        namespace: default
+        name: example-role
+      rules:
+        - apiGroups: [""]
+          resources: ["pods"]
+          verbs: ["get"]
 ----
 
-//=== How does this work?
+=== How does this work?
+
+The `exec` permissions are set by allowing the `create` verb for the `pods/exec` resource. Removing this permission will prevent users and services from executing arbitrary commands within containers.
 
 //=== Pitfalls
 
 //=== Going the extra mile
 
 
-//== Resources
-//=== Documentation
-//=== Articles & blog posts
-//=== Conference presentations
-//=== Standards
-//=== External coding guidelines
-//=== Benchmarks
+include::../kubernetes/resources.adoc[]
+
+ifdef::env-github,rspecator-view[]
+
+'''
+== Implementation Specification
+(visible only on this page)
+
+include::../kubernetes/message.adoc[]
+
+
+include::../kubernetes/highlighting.adoc[]
+
+
+endif::env-github,rspecator-view[]

rules/S6868/kubernetes/description.adoc

@@ -0,0 +1,19 @@
+== Why is this an issue?
+
+Allowing command execution (exec) for roles in a Kubernetes cluster can pose a significant security risk. This is because it provides the user with the ability to execute arbitrary commands within a container, potentially leading to unauthorized access or data breaches.
+
+In a production Kubernetes cluster, exec permissions are typically unnecessary due to the principle of least privilege, which suggests that a user or process should only have the minimum permissions necessary to perform its function. Additionally, containers in production are often treated as immutable infrastructure, meaning they should not be changed once deployed. Any changes should be made to the container image, which is then used to deploy a new container.
+
+=== What is the potential impact?
+
+==== Exploiting Vulnerabilities Within the Container
+
+If a user or service has the ability to execute commands within a container, they could potentially identify and exploit vulnerabilities within the container's software. This could include exploiting known vulnerabilities in outdated software versions, or finding and exploiting new vulnerabilities. This could lead to unauthorized access to the container, allowing the attacker to manipulate its operations or access its data.
+
+==== Installing Malicious Software
+
+Command execution permissions could also be used to install malicious software within a container. This could include malware, spyware, ransomware, or other types of harmful software. Once installed, this software could cause a wide range of issues, from data corruption or loss, to providing a backdoor for further attacks. It could also be used to create a botnet, using the compromised container to launch attacks on other systems.
+
+==== Extracting Sensitive Data
+
+If an attacker has the ability to execute commands within a container, they could potentially access and extract sensitive data. This could include user data, confidential business information, or other types of sensitive data. The extracted data could then be used for a wide range of malicious purposes, from identity theft to corporate espionage. This could lead to significant financial loss, damage to reputation, and potential legal consequences.

rules/S6868/kubernetes/highlighting.adoc

@@ -0,0 +1,3 @@
+=== Highlighting
+
+* Highlight the `resources` property.

rules/S6868/kubernetes/message.adoc

@@ -0,0 +1,3 @@
+=== Message
+
+Remove the command execution permission for this role.

rules/S6868/kubernetes/resources.adoc

@@ -0,0 +1,12 @@
+== Resources
+=== Documentation
+
+* Kubernetes Documentation - https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/[Get a Shell to a Running Container]
+
+//=== Articles & blog posts
+//=== Conference presentations
+=== Standards
+* CWE - https://cwe.mitre.org/data/definitions/284[CWE-284 - Improper Access Control]
+
+//=== External coding guidelines
+//=== Benchmarks

rules/S6868/kubernetes/rule.adoc

@@ -1,22 +1,4 @@
-== Why is this an issue?
-
-Allowing command execution (exec) for roles in a Kubernetes cluster can pose a significant security risk. This is because it provides the user with the ability to execute arbitrary commands within a container, potentially leading to unauthorized access or data breaches.
-
-In a production Kubernetes cluster, exec permissions are typically unnecessary due to the principle of least privilege, which suggests that a user or process should only have the minimum permissions necessary to perform its function. Additionally, containers in production are often treated as immutable infrastructure, meaning they should not be changed once deployed. Any changes should be made to the container image, which is then used to deploy a new container.
-
-=== What is the potential impact?
-
-==== Exploiting Vulnerabilities Within the Container
-
-If a user or service has the ability to execute commands within a container, they could potentially identify and exploit vulnerabilities within the container's software. This could include exploiting known vulnerabilities in outdated software versions, or finding and exploiting new vulnerabilities. This could lead to unauthorized access to the container, allowing the attacker to manipulate its operations or access its data.
-
-==== Installing Malicious Software
-
-Command execution permissions could also be used to install malicious software within a container. This could include malware, spyware, ransomware, or other types of harmful software. Once installed, this software could cause a wide range of issues, from data corruption or loss, to providing a backdoor for further attacks. It could also be used to create a botnet, using the compromised container to launch attacks on other systems.
-
-==== Extracting Sensitive Data
-
-If an attacker has the ability to execute commands within a container, they could potentially access and extract sensitive data. This could include user data, confidential business information, or other types of sensitive data. The extracted data could then be used for a wide range of malicious purposes, from identity theft to corporate espionage. This could lead to significant financial loss, damage to reputation, and potential legal consequences.
+include::description.adoc[]
 
 == How to fix it
 
@@ -64,33 +46,18 @@ The `exec` permissions are set by allowing the `create` verb for the `pods/exec`
 //=== Going the extra mile
 
 
-== Resources
-=== Documentation
-
-* Kubernetes Documentation - https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/[Get a Shell to a Running Container]
-
-//=== Articles & blog posts
-//=== Conference presentations
-=== Standards
-* CWE - https://cwe.mitre.org/data/definitions/284[CWE-284 - Improper Access Control]
-
-//=== External coding guidelines
-//=== Benchmarks
+include::resources.adoc[]
 
 ifdef::env-github,rspecator-view[]
 
 '''
 == Implementation Specification
 (visible only on this page)
 
-=== Message
-
-Remove the command execution permission for this role.
-
+include::message.adoc[]
 
-=== Highlighting
 
-* Highlight the `resources` property.
+include::highlighting.adoc[]
 
 
 endif::env-github,rspecator-view[]