Create rule S6867 (#3511)

* Create rule S6867

Co-authored-by: hendrik-buchwald-sonarsource <64110887+hendrik-buchwald-sonarsource@users.noreply.github.com>

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