Merge branch 'master' into rule/add-RSPEC-S6868

rules/S6865/kubernetes/metadata.json

@@ -0,0 +1,24 @@
+{
+  "title": "Service account tokens should not be mounted in pods",
+  "type": "VULNERABILITY",
+  "status": "ready",
+  "remediation": {
+    "func": "Constant\/Issue",
+    "constantCost": "5min"
+  },
+  "tags": [
+  ],
+  "defaultSeverity": "Major",
+  "ruleSpecification": "RSPEC-6865",
+  "sqKey": "S6865",
+  "scope": "All",
+  "defaultQualityProfiles": ["Sonar way"],
+  "quickfix": "unknown",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM",
+      "SECURITY": "MEDIUM"
+    },
+    "attribute": "COMPLETE"
+  }
+}

rules/S6865/kubernetes/rule.adoc

@@ -0,0 +1,115 @@
+== Why is this an issue?
+
+Service account tokens are Kubernetes secrets created automatically to authenticate applications running inside pods to the API server. If a pod is compromised, an attacker could use this token to gain access to other resources in the cluster.
+
+For example, they could create new pods, modify existing ones, or even delete critical system pods, depending on the permissions associated with the service account.
+
+Therefore, it's recommended to disable the automounting of service account tokens when it's not necessary for the application running in the pod.
+
+=== What is the potential impact?
+
+==== Unauthorized Access
+If a pod with a mounted service account gets compromised, an attacker could potentially use the token to interact with the Kubernetes API, possibly leading to unauthorized access to other resources in the cluster.
+
+==== Privilege Escalation
+Service account tokens are often bound with roles that have extensive permissions. If these tokens are exposed, it could lead to privilege escalation where an attacker gains higher-level permissions than intended.
+
+==== Data Breach
+Service account tokens can be used to access sensitive data stored in the Kubernetes cluster. If these tokens are compromised, it could lead to a data breach.
+
+==== Denial of Service
+An attacker with access to a service account token could potentially overload the Kubernetes API server by sending a large number of requests, leading to a Denial of Service (DoS) attack.
+
+
+== How to fix it
+//== How to fix it in FRAMEWORK NAME
+
+=== Code examples
+
+==== Noncompliant code example
+
+[source,yaml,diff-id=1,diff-type=noncompliant]
+----
+apiVersion: v1
+kind: Pod
+metadata:
+  name: example-pod
+spec:
+  containers: # Noncompliant
+  - name: example-pod
+    image: nginx:1.25.3
+----
+
+==== Compliant solution
+
+[source,yaml,diff-id=1,diff-type=compliant]
+----
+apiVersion: v1
+kind: Pod
+metadata:
+  name: example-pod
+spec:
+  containers:
+  - name: example-pod
+    image: nginx:1.25.3
+  automountServiceAccountToken: false
+
+----
+
+The same can be achieved by setting `automountServiceAccountToken: false` in the service account's configuration:
+
+[source,yaml]
+----
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: example-service-account
+  namespace: default
+automountServiceAccountToken: false
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: example-pod
+spec:
+  containers:
+  - name: example-pod
+    image: nginx:1.25.3
+  serviceAccountName: example-service-account
+----
+
+=== How does this work?
+
+The automounting of service account tokens can be disabled by setting `automountServiceAccountToken: false` in the pod's specification or in the service account's configuration.
+
+
+// === Pitfalls
+//=== Going the extra mile
+
+
+== Resources
+=== Documentation
+
+* Kubernetes Documentation - https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/[Configure Service Accounts for Pods]
+
+//=== Articles & blog posts
+//=== Conference presentations
+//=== Standards
+//=== External coding guidelines
+//=== Benchmarks
+
+ifdef::env-github,rspecator-view[]
+
+'''
+== Implementation Specification
+(visible only on this page)
+
+=== Message
+
+Set automountServiceAccountToken to false for this container.
+
+
+=== Highlighting
+
+* Highlight the `containers` property.
+endif::env-github,rspecator-view[]

rules/S6865/metadata.json

@@ -0,0 +1,2 @@
+{
+}

rules/S6867/kubernetes/metadata.json

@@ -0,0 +1,29 @@
+{
+  "title": "Wildcards should not be used to define RBAC permissions",
+  "type": "VULNERABILITY",
+  "status": "ready",
+  "remediation": {
+    "func": "Constant\/Issue",
+    "constantCost": "5min"
+  },
+  "tags": [
+  ],
+  "defaultSeverity": "Major",
+  "ruleSpecification": "RSPEC-6867",
+  "sqKey": "S6864",
+  "scope": "All",
+  "securityStandards": {
+    "CWE": [
+      284
+    ]
+  },
+  "defaultQualityProfiles": ["Sonar way"],
+  "quickfix": "unknown",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "MEDIUM",
+      "SECURITY": "MEDIUM"
+    },
+    "attribute": "COMPLETE"
+  }
+}

rules/S6867/kubernetes/rule.adoc

@@ -0,0 +1,85 @@
+== Why is this an issue?
+
+Using wildcards when defining Role-Based Access Control (RBAC) permissions in Kubernetes can lead to significant security issues. This is because it grants overly broad permissions, potentially allowing access to sensitive resources.
+
+
+RBAC is designed to limit the access rights of users within the system by assigning roles to them. These roles define what actions a user can perform and on which resources. When a wildcard is used, it means that the role has access to all resources/verbs, bypassing the principle of least privilege. This principle states that users should have only the minimal permissions they need to perform their job function.
+
+
+=== What is the potential impact?
+
+If an attacker gains access to a role with wildcard permissions, they could potentially read, modify, or delete any resource in the Kubernetes cluster, leading to data breaches, service disruptions, or other malicious activities.
+
+== How to fix it
+
+=== Code examples
+
+==== Noncompliant code example
+
+[source,yaml,diff-id=1,diff-type=noncompliant]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  namespace: default
+  name: example-role
+rules:
+  - apiGroups: [""]
+    resources: ["*"] # Noncompliant
+    verbs: ["get", "list"]
+----
+
+==== Compliant solution
+
+[source,yaml,diff-id=1,diff-type=compliant]
+----
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  namespace: default
+  name: example-role
+rules:
+  - apiGroups: [""]
+    resources: ["pods"]
+    verbs: ["get", "list"]
+----
+
+=== How does this work?
+
+When defining RBAC permissions, it is important to follow the principle of least privilege. By explicitly specifying the verbs and resources a user should have access to instead of using wildcards, it can be ensured that users have only the permissions they need to perform their job function.
+
+//=== Pitfalls
+
+//=== Going the extra mile
+
+
+== Resources
+=== Documentation
+
+* Kubernetes Documentation - https://kubernetes.io/docs/reference/access-authn-authz/rbac/[Using RBAC Authorization]
+
+
+//=== Articles & blog posts
+//=== Conference presentations
+=== Standards
+
+* https://cwe.mitre.org/data/definitions/284[MITRE, CWE-284] - Improper Access Control
+
+//=== External coding guidelines
+//=== Benchmarks
+
+ifdef::env-github,rspecator-view[]
+
+'''
+== Implementation Specification
+(visible only on this page)
+
+=== Message
+
+Do not use wildcards when defining RBAC permissions.
+
+
+=== Highlighting
+
+* Highlight the property that was set using a wildcart.
+endif::env-github,rspecator-view[]

rules/S6867/metadata.json

@@ -0,0 +1,2 @@
+{
+}