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

frontend/public/covered_rules.json

@@ -3071,11 +3071,11 @@
     "S6832": "sonar-java 7.28.0.33738",
     "S6833": "sonar-java 7.28.0.33738",
     "S6837": "sonar-java 7.28.0.33738",
-    "S6838": "sonar-java master",
-    "S6856": "sonar-java master",
-    "S6857": "sonar-java master",
-    "S6862": "sonar-java master",
-    "S6863": "sonar-java master",
+    "S6838": "sonar-java 7.30.0.34429",
+    "S6856": "sonar-java 7.30.0.34429",
+    "S6857": "sonar-java 7.30.0.34429",
+    "S6862": "sonar-java 7.30.0.34429",
+    "S6863": "sonar-java 7.30.0.34429",
     "S818": "sonar-java 4.15.0.12310",
     "S864": "sonar-java 4.15.0.12310",
     "S881": "sonar-java 4.15.0.12310",
@@ -4913,7 +4913,7 @@
     "S6776": "sonar-security master",
     "S6779": "sonar-python 4.11.0.13826",
     "S6781": "sonar-python 4.11.0.13826",
-    "S6785": "sonar-python master",
+    "S6785": "sonar-python 4.14.0.14263",
     "S6786": "sonar-python 4.11.0.13826",
     "S6792": "sonar-python 4.10.0.13725",
     "S6794": "sonar-python 4.10.0.13725",

rules/S6864/kubernetes/rule.adoc

@@ -76,9 +76,7 @@ spec:
 
 A limit can be set through the property `resources.limits.memory` of a
 container. Alternatively, a default limit for a namespace can be set with
-`LimitRange`. This will not prevent issues from being raised, since it is not
-clear what containers it will apply to at the time of analysis. A separate limit
-for each container is preferable.
+`LimitRange`.
 
 == Resources
 

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 @@
+{
+}