|
|
|
|
@@ -5,19 +5,19 @@
|
|
|
|
|
Ici, vous pouvez trouver certaines configurations de Roles et ClusterRoles potentiellement dangereuses.\
|
|
|
|
|
N'oubliez pas que vous pouvez obtenir toutes les ressources prises en charge avec `kubectl api-resources`
|
|
|
|
|
|
|
|
|
|
## **Escalade de Privilèges**
|
|
|
|
|
## **Élévation de Privilèges**
|
|
|
|
|
|
|
|
|
|
Se référant à l'art d'obtenir **l'accès à un principal différent** au sein du cluster **avec des privilèges différents** (au sein du cluster kubernetes ou vers des clouds externes) de ceux que vous avez déjà, dans Kubernetes, il existe essentiellement **4 techniques principales pour escalader les privilèges** :
|
|
|
|
|
Se référant à l'art d'obtenir **l'accès à un autre principal** au sein du cluster **avec des privilèges différents** (au sein du cluster kubernetes ou vers des clouds externes) de ceux que vous avez déjà, dans Kubernetes, il existe essentiellement **4 techniques principales pour élever les privilèges** :
|
|
|
|
|
|
|
|
|
|
- Être capable de **se faire passer pour** d'autres utilisateurs/groupes/SAs avec de meilleurs privilèges au sein du cluster kubernetes ou vers des clouds externes
|
|
|
|
|
- Être capable de **créer/patcher/exécuter des pods** où vous pouvez **trouver ou attacher des SAs** avec de meilleurs privilèges au sein du cluster kubernetes ou vers des clouds externes
|
|
|
|
|
- Être capable de **lire des secrets** car les tokens des SAs sont stockés en tant que secrets
|
|
|
|
|
- Être capable de **s'échapper vers le nœud** depuis un conteneur, où vous pouvez voler tous les secrets des conteneurs en cours d'exécution sur le nœud, les identifiants du nœud et les permissions du nœud au sein du cloud dans lequel il s'exécute (le cas échéant)
|
|
|
|
|
- Être capable de **s'échapper vers le nœud** depuis un conteneur, où vous pouvez voler tous les secrets des conteneurs en cours d'exécution sur le nœud, les identifiants du nœud, et les permissions du nœud au sein du cloud dans lequel il s'exécute (le cas échéant)
|
|
|
|
|
- Une cinquième technique qui mérite d'être mentionnée est la capacité de **faire un port-forward** dans un pod, car vous pourriez être en mesure d'accéder à des ressources intéressantes au sein de ce pod.
|
|
|
|
|
|
|
|
|
|
### Accéder à n'importe quelle ressource ou verbe (Wildcard)
|
|
|
|
|
|
|
|
|
|
Le **wildcard (\*) donne la permission sur n'importe quelle ressource avec n'importe quel verbe**. Il est utilisé par les administrateurs. À l'intérieur d'un ClusterRole, cela signifie qu'un attaquant pourrait abuser de n'importe quel namespace dans le cluster.
|
|
|
|
|
Le **wildcard (\*) donne la permission sur n'importe quelle ressource avec n'importe quel verbe**. Il est utilisé par les administrateurs. À l'intérieur d'un ClusterRole, cela signifie qu'un attaquant pourrait abuser de n'importe quel namespace dans le cluster
|
|
|
|
|
```yaml
|
|
|
|
|
apiVersion: rbac.authorization.k8s.io/v1
|
|
|
|
|
kind: ClusterRole
|
|
|
|
|
@@ -34,7 +34,7 @@ verbs: ["*"]
|
|
|
|
|
Dans RBAC, certaines permissions présentent des risques significatifs :
|
|
|
|
|
|
|
|
|
|
1. **`create`:** Accorde la capacité de créer n'importe quelle ressource de cluster, risquant une élévation de privilèges.
|
|
|
|
|
2. **`list`:** Permet de lister toutes les ressources, pouvant potentiellement divulguer des données sensibles.
|
|
|
|
|
2. **`list`:** Permet de lister toutes les ressources, pouvant potentiellement entraîner une fuite de données sensibles.
|
|
|
|
|
3. **`get`:** Permet d'accéder aux secrets des comptes de service, posant une menace pour la sécurité.
|
|
|
|
|
```yaml
|
|
|
|
|
apiVersion: rbac.authorization.k8s.io/v1
|
|
|
|
|
@@ -49,7 +49,7 @@ verbs: ["create", "list", "get"]
|
|
|
|
|
```
|
|
|
|
|
### Pod Create - Steal Token
|
|
|
|
|
|
|
|
|
|
Un attaquant ayant les permissions de créer un pod pourrait attacher un compte de service privilégié dans le pod et voler le jeton pour usurper l'identité du compte de service. Cela permet d'escalader effectivement les privilèges.
|
|
|
|
|
Un attaquant ayant les permissions de créer un pod pourrait attacher un compte de service privilégié dans le pod et voler le jeton pour usurper l'identité du compte de service. Élevant ainsi effectivement ses privilèges.
|
|
|
|
|
|
|
|
|
|
Exemple d'un pod qui volera le jeton du compte de service `bootstrap-signer` et l'enverra à l'attaquant :
|
|
|
|
|
```yaml
|
|
|
|
|
@@ -72,7 +72,7 @@ serviceAccountName: bootstrap-signer
|
|
|
|
|
automountServiceAccountToken: true
|
|
|
|
|
hostNetwork: true
|
|
|
|
|
```
|
|
|
|
|
### Création de Pod & Évasion
|
|
|
|
|
### Création et Évasion de Pod
|
|
|
|
|
|
|
|
|
|
Les éléments suivants indiquent tous les privilèges qu'un conteneur peut avoir :
|
|
|
|
|
|
|
|
|
|
@@ -127,7 +127,7 @@ Maintenant que vous pouvez échapper au nœud, consultez les techniques post-exp
|
|
|
|
|
|
|
|
|
|
#### Stealth
|
|
|
|
|
|
|
|
|
|
Vous voulez probablement être **plus furtif**. Dans les pages suivantes, vous pouvez voir ce à quoi vous pourriez accéder si vous créez un pod en n'activant que certains des privilèges mentionnés dans le modèle précédent :
|
|
|
|
|
Vous voulez probablement être **plus furtif**, dans les pages suivantes, vous pouvez voir ce à quoi vous pourriez accéder si vous créez un pod en n'activant que certains des privilèges mentionnés dans le modèle précédent :
|
|
|
|
|
|
|
|
|
|
- **Privileged + hostPID**
|
|
|
|
|
- **Privileged only**
|
|
|
|
|
@@ -136,11 +136,11 @@ Vous voulez probablement être **plus furtif**. Dans les pages suivantes, vous p
|
|
|
|
|
- **hostNetwork**
|
|
|
|
|
- **hostIPC**
|
|
|
|
|
|
|
|
|
|
_Vous pouvez trouver un exemple de comment créer/abuser des configurations de pods privilégiés précédentes dans_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
|
|
|
|
|
_Vous pouvez trouver un exemple de comment créer/abuser des configurations de pods privilégiés précédents dans_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)
|
|
|
|
|
|
|
|
|
|
### Pod Create - Move to cloud
|
|
|
|
|
|
|
|
|
|
Si vous pouvez **créer** un **pod** (et éventuellement un **compte de service**), vous pourriez être en mesure de **obtenir des privilèges dans l'environnement cloud** en **assignant des rôles cloud à un pod ou à un compte de service** et ensuite y accéder.\
|
|
|
|
|
Si vous pouvez **créer** un **pod** (et éventuellement un **compte de service**), vous pourriez être en mesure de **obtenir des privilèges dans un environnement cloud** en **assignant des rôles cloud à un pod ou à un compte de service** et ensuite y accéder.\
|
|
|
|
|
De plus, si vous pouvez créer un **pod avec l'espace de noms réseau de l'hôte**, vous pouvez **voler le rôle IAM** de l'instance **node**.
|
|
|
|
|
|
|
|
|
|
Pour plus d'informations, consultez :
|
|
|
|
|
@@ -199,19 +199,19 @@ kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh
|
|
|
|
|
```
|
|
|
|
|
### port-forward
|
|
|
|
|
|
|
|
|
|
Cette permission permet de **rediriger un port local vers un port dans le pod spécifié**. Cela est destiné à faciliter le débogage des applications s'exécutant à l'intérieur d'un pod, mais un attaquant pourrait en abuser pour accéder à des applications intéressantes (comme des bases de données) ou vulnérables (webs ?) à l'intérieur d'un pod :
|
|
|
|
|
Cette permission permet de **transférer un port local vers un port dans le pod spécifié**. Cela est destiné à faciliter le débogage des applications s'exécutant à l'intérieur d'un pod, mais un attaquant pourrait en abuser pour accéder à des applications intéressantes (comme des bases de données) ou vulnérables (webs ?) à l'intérieur d'un pod :
|
|
|
|
|
```
|
|
|
|
|
kubectl port-forward pod/mypod 5000:5000
|
|
|
|
|
```
|
|
|
|
|
### Hôtes Écrits /var/log/ Évasion
|
|
|
|
|
|
|
|
|
|
Comme [**indiqué dans cette recherche**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), si vous pouvez accéder ou créer un pod avec le **répertoire `/var/log/` des hôtes monté** dessus, vous pouvez **vous échapper du conteneur**.\
|
|
|
|
|
C'est essentiellement parce que lorsque le **Kube-API essaie d'obtenir les journaux** d'un conteneur (en utilisant `kubectl logs <pod>`), il **demande le fichier `0.log`** du pod en utilisant le point de terminaison `/logs/` du service **Kubelet**.\
|
|
|
|
|
C'est essentiellement parce que lorsque le **Kube-API essaie d'obtenir les logs** d'un conteneur (en utilisant `kubectl logs <pod>`), il **demande le fichier `0.log`** du pod en utilisant le point de terminaison `/logs/` du service **Kubelet**.\
|
|
|
|
|
Le service Kubelet expose le point de terminaison `/logs/` qui expose essentiellement **le système de fichiers `/var/log` du conteneur**.
|
|
|
|
|
|
|
|
|
|
Par conséquent, un attaquant ayant **accès en écriture dans le dossier /var/log/** du conteneur pourrait abuser de ce comportement de 2 manières :
|
|
|
|
|
|
|
|
|
|
- Modifier le fichier `0.log` de son conteneur (généralement situé dans `/var/logs/pods/namespace_pod_uid/container/0.log`) pour qu'il soit un **lien symbolique pointant vers `/etc/shadow`** par exemple. Ensuite, vous pourrez exfiltrer le fichier shadow des hôtes en faisant :
|
|
|
|
|
- Modifier le fichier `0.log` de son conteneur (généralement situé dans `/var/logs/pods/namespace_pod_uid/container/0.log`) pour qu'il soit un **symlink pointant vers `/etc/shadow`** par exemple. Ensuite, vous pourrez exfiltrer le fichier shadow des hôtes en faisant :
|
|
|
|
|
```bash
|
|
|
|
|
kubectl logs escaper
|
|
|
|
|
failed to get parse function: unsupported log format: "root::::::::\n"
|
|
|
|
|
@@ -219,7 +219,7 @@ kubectl logs escaper --tail=2
|
|
|
|
|
failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n"
|
|
|
|
|
# Keep incrementing tail to exfiltrate the whole file
|
|
|
|
|
```
|
|
|
|
|
- Si l'attaquant contrôle un principal avec les **permissions pour lire `nodes/log`**, il peut simplement créer un **symlink** dans `/host-mounted/var/log/sym` vers `/` et lorsqu'il **accède à `https://<gateway>:10250/logs/sym/`, il listera le système de fichiers racine** de l'hôte (changer le symlink peut fournir un accès à des fichiers).
|
|
|
|
|
- Si l'attaquant contrôle un principal avec les **permissions pour lire `nodes/log`**, il peut simplement créer un **symlink** dans `/host-mounted/var/log/sym` vers `/` et en **accédant à `https://<gateway>:10250/logs/sym/`, il listera le système de fichiers racine** de l'hôte (changer le symlink peut fournir un accès à des fichiers).
|
|
|
|
|
```bash
|
|
|
|
|
curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
|
|
|
|
|
<a href="bin">bin</a>
|
|
|
|
|
@@ -476,7 +476,7 @@ groups:
|
|
|
|
|
> [!WARNING]
|
|
|
|
|
> Vous pouvez utiliser **`aws-auth`** pour **la persistance** en donnant accès à des utilisateurs d'**autres comptes**.
|
|
|
|
|
>
|
|
|
|
|
> Cependant, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **ne fonctionne pas depuis un compte différent**. Mais en réalité, `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` fonctionne si vous mettez l'ARN du cluster au lieu de juste le nom.\
|
|
|
|
|
> Cependant, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **ne fonctionne pas depuis un compte différent**. Mais en réalité, `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` fonctionne si vous mettez l'ARN du cluster au lieu du simple nom.\
|
|
|
|
|
> Pour faire fonctionner `kubectl`, assurez-vous simplement de **configurer** le **kubeconfig de la victime** et dans les arguments d'exécution aws, ajoutez `--profile other_account_role` afin que kubectl utilise le profil de l'autre compte pour obtenir le token et contacter AWS.
|
|
|
|
|
|
|
|
|
|
### Escalade dans GKE
|
|
|
|
|
@@ -485,7 +485,7 @@ Il existe **2 façons d'assigner des permissions K8s aux principaux GCP**. Dans
|
|
|
|
|
|
|
|
|
|
> [!WARNING]
|
|
|
|
|
> Lorsqu'il communique avec le point de terminaison API K8s, le **token d'authentification GCP sera envoyé**. Ensuite, GCP, via le point de terminaison API K8s, vérifiera d'abord si le **principal** (par e-mail) **a un accès à l'intérieur du cluster**, puis il vérifiera s'il a **un accès via GCP IAM**.\
|
|
|
|
|
> Si **l'un** de ces éléments est **vrai**, il sera **répondu**. Si **non**, une **erreur** suggérant de donner **des permissions via GCP IAM** sera donnée.
|
|
|
|
|
> Si **l'un** de ces éléments est **vrai**, il sera **répondu**. Sinon, une **erreur** suggérant de donner **des permissions via GCP IAM** sera donnée.
|
|
|
|
|
|
|
|
|
|
Ensuite, la première méthode consiste à utiliser **GCP IAM**, les permissions K8s ont leurs **permissions GCP IAM équivalentes**, et si le principal les a, il pourra les utiliser.
|
|
|
|
|
|
|
|
|
|
@@ -505,9 +505,9 @@ Les principaux qui peuvent **`update`** ou **`patch`** **`pods/ephemeralcontaine
|
|
|
|
|
|
|
|
|
|
### ValidatingWebhookConfigurations ou MutatingWebhookConfigurations
|
|
|
|
|
|
|
|
|
|
Les principaux ayant l'un des verbes `create`, `update` ou `patch` sur `validatingwebhookconfigurations` ou `mutatingwebhookconfigurations` pourraient être en mesure de **créer l'une de ces configurations de webhook** afin de pouvoir **escalader les privilèges**.
|
|
|
|
|
Les principaux avec l'un des verbes `create`, `update` ou `patch` sur `validatingwebhookconfigurations` ou `mutatingwebhookconfigurations` pourraient être en mesure de **créer l'une de ces webhookconfigurations** afin de pouvoir **escalader les privilèges**.
|
|
|
|
|
|
|
|
|
|
Pour un exemple de [`mutatingwebhookconfigurations`, consultez cette section de ce post](#malicious-admission-controller).
|
|
|
|
|
Pour un [`exemple de mutatingwebhookconfigurations, consultez cette section de ce post`](#malicious-admission-controller).
|
|
|
|
|
|
|
|
|
|
### Escalader
|
|
|
|
|
|
|
|
|
|
@@ -516,7 +516,7 @@ Alors il peut mettre à jour/créer de nouveaux rôles, clusterroles avec de mei
|
|
|
|
|
|
|
|
|
|
### Proxy des nœuds
|
|
|
|
|
|
|
|
|
|
Les principaux ayant accès à la sous-ressource **`nodes/proxy`** peuvent **exécuter du code sur des pods** via l'API Kubelet (selon [**ceci**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Plus d'informations sur l'authentification Kubelet sur cette page :
|
|
|
|
|
Les principaux ayant accès à la **sous-ressource `nodes/proxy`** peuvent **exécuter du code sur des pods** via l'API Kubelet (selon [**ceci**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Plus d'informations sur l'authentification Kubelet sur cette page :
|
|
|
|
|
|
|
|
|
|
{{#ref}}
|
|
|
|
|
../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
|
|
|
|
|
@@ -526,7 +526,7 @@ Vous avez un exemple de comment obtenir [**RCE en parlant autorisé à une API K
|
|
|
|
|
|
|
|
|
|
### Supprimer des pods + nœuds non planifiables
|
|
|
|
|
|
|
|
|
|
Les principaux qui peuvent **supprimer des pods** (verbe `delete` sur la ressource `pods`), ou **évincer des pods** (verbe `create` sur la ressource `pods/eviction`), ou **changer le statut des pods** (accès à `pods/status`) et peuvent **rendre d'autres nœuds non planifiables** (accès à `nodes/status`) ou **supprimer des nœuds** (verbe `delete` sur la ressource `nodes`) et ont le contrôle sur un pod, pourraient **voler des pods d'autres nœuds** afin qu'ils soient **exécutés** dans le **nœud compromis** et l'attaquant peut **voler les tokens** de ces pods.
|
|
|
|
|
Les principaux qui peuvent **supprimer des pods** (verbe `delete` sur la ressource `pods`), ou **évincer des pods** (verbe `create` sur la ressource `pods/eviction`), ou **changer le statut des pods** (accès à `pods/status`) et peuvent **rendre d'autres nœuds non planifiables** (accès à `nodes/status`) ou **supprimer des nœuds** (verbe `delete` sur la ressource `nodes`) et ont le contrôle sur un pod, pourraient **voler des pods d'autres nœuds** afin qu'ils soient **exécutés** dans le **nœud compromis** et que l'attaquant puisse **voler les tokens** de ces pods.
|
|
|
|
|
```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"}]'
|
|
|
|
|
@@ -549,12 +549,12 @@ Les principaux avec des permissions **`update`** ou **`patch`** sur `nodes/statu
|
|
|
|
|
|
|
|
|
|
Kubernetes a un [mécanisme intégré](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) pour prévenir l'escalade de privilèges.
|
|
|
|
|
|
|
|
|
|
Ce système garantit que **les utilisateurs ne peuvent pas élever leurs privilèges en modifiant des rôles ou des liaisons de rôles**. L'application de cette règle se produit au niveau de l'API, fournissant une protection même lorsque l'autorisateur RBAC est inactif.
|
|
|
|
|
Ce système garantit que **les utilisateurs ne peuvent pas élever leurs privilèges en modifiant des rôles ou des liaisons de rôles**. L'application de cette règle se produit au niveau de l'API, fournissant une protection même lorsque l'autorisation RBAC est inactive.
|
|
|
|
|
|
|
|
|
|
La règle stipule qu'un **utilisateur ne peut créer ou mettre à jour un rôle que s'il possède toutes les permissions que le rôle comprend**. De plus, la portée des permissions existantes de l'utilisateur doit correspondre à celle du rôle qu'il tente de créer ou de modifier : soit à l'échelle du cluster pour les ClusterRoles, soit confinée au même espace de noms (ou à l'échelle du cluster) pour les Roles.
|
|
|
|
|
|
|
|
|
|
> [!WARNING]
|
|
|
|
|
> Il existe une exception à la règle précédente. Si un principal a le **verbe `escalate`** sur **`roles`** ou **`clusterroles`**, il peut augmenter les privilèges des rôles et des clusterroles même sans avoir les permissions lui-même.
|
|
|
|
|
> Il y a une exception à la règle précédente. Si un principal a le **verbe `escalate`** sur **`roles`** ou **`clusterroles`**, il peut augmenter les privilèges des rôles et des clusterroles même sans avoir les permissions lui-même.
|
|
|
|
|
|
|
|
|
|
### **Get & Patch RoleBindings/ClusterRoleBindings**
|
|
|
|
|
|
|
|
|
|
@@ -571,11 +571,11 @@ Par défaut, il n'y a pas de cryptage dans la communication entre les pods. Auth
|
|
|
|
|
|
|
|
|
|
#### Create a sidecar proxy app <a href="#create-a-sidecar-proxy-app" id="create-a-sidecar-proxy-app"></a>
|
|
|
|
|
|
|
|
|
|
Create your .yaml
|
|
|
|
|
Créez votre .yaml
|
|
|
|
|
```bash
|
|
|
|
|
kubectl run app --image=bash --command -oyaml --dry-run=client > <appName.yaml> -- sh -c 'ping google.com'
|
|
|
|
|
```
|
|
|
|
|
Éditez votre .yaml et ajoutez les lignes non commentées :
|
|
|
|
|
Éditez votre .yaml et ajoutez les lignes décommentées :
|
|
|
|
|
```yaml
|
|
|
|
|
#apiVersion: v1
|
|
|
|
|
#kind: Pod
|
|
|
|
|
@@ -615,7 +615,7 @@ Plus d'infos sur : [https://kubernetes.io/docs/tasks/configure-pod-container/sec
|
|
|
|
|
|
|
|
|
|
### Contrôleur d'admission malveillant
|
|
|
|
|
|
|
|
|
|
Un contrôleur d'admission **intercepte les requêtes vers le serveur API Kubernetes** avant la persistance de l'objet, mais **après que la requête a été authentifiée** **et autorisée**.
|
|
|
|
|
Un contrôleur d'admission **intercepte les requêtes vers le serveur API Kubernetes** avant la persistance de l'objet, mais **après que la requête soit authentifiée** **et autorisée**.
|
|
|
|
|
|
|
|
|
|
Si un attaquant parvient d'une manière ou d'une autre à **injecter un contrôleur d'admission de mutation**, il pourra **modifier des requêtes déjà authentifiées**. Cela peut potentiellement permettre une élévation de privilèges, et plus généralement persister dans le cluster.
|
|
|
|
|
|
|
|
|
|
@@ -645,7 +645,7 @@ kubectl describe po nginx | grep "Image: "
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Comme vous pouvez le voir dans l'image ci-dessus, nous avons essayé d'exécuter l'image `nginx`, mais l'image finalement exécutée est `rewanthtammana/malicious-image`. Que s'est-il passé !!?
|
|
|
|
|
Comme vous pouvez le voir dans l'image ci-dessus, nous avons essayé d'exécuter l'image `nginx`, mais l'image exécutée finale est `rewanthtammana/malicious-image`. Que s'est-il passé !!?
|
|
|
|
|
|
|
|
|
|
#### Technicalities <a href="#heading-technicalities" id="heading-technicalities"></a>
|
|
|
|
|
|
|
|
|
|
@@ -672,7 +672,7 @@ Le snippet ci-dessus remplace la première image de conteneur dans chaque pod pa
|
|
|
|
|
- **Pods et Comptes de Service** : Par défaut, les pods montent un jeton de compte de service. Pour améliorer la sécurité, Kubernetes permet de désactiver cette fonctionnalité d'automontage.
|
|
|
|
|
- **Comment Appliquer** : Définissez `automountServiceAccountToken: false` dans la configuration des comptes de service ou des pods à partir de la version 1.6 de Kubernetes.
|
|
|
|
|
|
|
|
|
|
### **Attribution Restrictive des Utilisateurs dans les RoleBindings/ClusterRoleBindings**
|
|
|
|
|
### **Attribution d'Utilisateurs Restrictive dans RoleBindings/ClusterRoleBindings**
|
|
|
|
|
|
|
|
|
|
- **Inclusion Sélective** : Assurez-vous que seuls les utilisateurs nécessaires sont inclus dans les RoleBindings ou ClusterRoleBindings. Auditez régulièrement et retirez les utilisateurs non pertinents pour maintenir une sécurité stricte.
|
|
|
|
|
|
|
|
|
|
|
Translator