RBAC et comptes de service
Sécuriser l’accès aux grappes.
RBAC et comptes de service est une leçon Cyber Security Academy gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Cyber Security Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Cyber Security Academy comprend 4 leçons au total.
RBAC contrôle tout
Le contrôle d’accès basé sur les rôles (RBAC) détermine quelles identités peuvent effectuer quelles actions sur quelles ressources dans un cluster. Chaque appel d’API est autorisé conformément à RBAC. Une configuration RBAC incorrecte est la principale cause d’élévation de privilèges au sein du cluster.
- Sujets : utilisateurs, groupes, comptes de service.
- Les rôles associent des verbes à des ressources.
- Les liaisons relient les sujets aux rôles.
Rôles et ClusterRoles
Deux portées existent.
- Role + RoleBinding : autorisations limitées à un espace de noms.
- ClusterRole + ClusterRoleBinding : autorisations à l’échelle du cluster.
Une liaison ClusterRoleBinding vers cluster-admin donne un contrôle total. L’accorder à un compte de service est une erreur fréquente et dangereuse.
Jetons des comptes de service
Chaque pod s’exécute sous l’identité d’un compte de service et monte son jeton par défaut. Ce jeton porteur contient les droits RBAC du compte. Si le pod est compromis, le jeton l’est également.
Les clusters modernes émettent des jetons projetés à courte durée de vie et liés à une audience, mais d’anciens jetons de secrets à longue durée de vie subsistent encore.
# Inspect which service account a pod uses
kubectl get pod web -o jsonpath='{.spec.serviceAccountName}'Énumération de vos autorisations
Après avoir récupéré un jeton, la première étape consiste à déterminer ce qu’il permet de faire. Kubernetes fournit une API d’auto-vérification.
# What can this token do?
kubectl auth can-i --list
# Specific checks
kubectl auth can-i create pods
kubectl auth can-i create clusterrolebindingsCombinaisons d’autorisations dangereuses
Certains verbes permettent une élévation de privilèges à eux seuls, même sans accès d’administrateur du cluster.
create pods: planifier un pod privilégié ou un pod utilisant hostPath pour s’évader.create pods/exec: exécuter des commandes dans des pods existants.get/list secrets: lire les secrets contenant des identifiants dans tout le cluster.create rolebindings/clusterrolebindings: vous accorder des droits d’administrateur.- Verbes
escalate/bind: accorder des droits que vous ne détenez pas. - Usurpation : agir en tant qu’un autre sujet plus privilégié.
Élévation de privilèges par création de pods
Si un compte de service peut créer des pods, il peut souvent prendre le contrôle du nœud. L’attaquant planifie un pod qui monte le système de fichiers de l’hôte ou s’exécute avec des privilèges, puis lit les identifiants du nœud ou s’évade.
# Pod spec snippet that mounts the host root
# volumes: hostPath path: / ; container mounts it at /host
kubectl apply -f evil-pod.yaml
kubectl exec -it evil -- chroot /host bashÉlévation de privilèges par liaison
Si vous pouvez créer des liaisons de rôles ou de rôles de cluster, vous pouvez associer directement votre compte de service à l’administrateur du cluster. Kubernetes protège cette opération avec les verbes bind/escalate, mais des rôles mal configurés l’autorisent parfois.
# Bind a service account to cluster-admin (if permitted)
kubectl create clusterrolebinding pwn \
--clusterrole=cluster-admin \
--serviceaccount=default:webAbus de l’usurpation
Le verbe impersonate permet à un sujet d’agir en tant qu’utilisateur, groupe ou compte de service. Une identité disposant de larges droits d’usurpation détient de fait toutes les autorisations du cluster.
# Act as a privileged user via impersonation
kubectl get secrets --as=admin-user --as-group=system:mastersAudit de RBAC
Les défenseurs doivent examiner en continu RBAC afin de repérer les autorisations risquées.
- Repérez les sujets liés à l’administrateur du cluster.
- Signalez les verbes ou ressources génériques (
*). - Détectez les autorisations de lecture des secrets et de création de pods accordées à des comptes non administrateurs.
# Tools to audit RBAC
kubectl-who-can create pods
rbac-tool analysis
rakkess --as=system:serviceaccount:default:webRenforcement des comptes de service
Appliquez le principe du moindre privilège aux identités.
- Définissez
automountServiceAccountToken: falselorsque le pod n’a pas besoin d’accéder à l’API. - Attribuez à chaque charge de travail un compte de service dédié, doté d’autorisations minimales.
- Évitez le compte de service
defaultpour les charges de travail réelles. - Utilisez des jetons projetés à courte durée de vie, avec des audiences ; renouvelez-les et liez-les.
- N’associez jamais des charges de travail à l’administrateur du cluster.
Évaluer RBAC de manière éthique
Lors de l’évaluation de RBAC, préférez les vérifications non destructives (auth can-i, simulation) à la création effective de liaisons vers l’administrateur du cluster en production. Si vous devez prouver une élévation de privilèges, limitez-la à un espace de noms d’évaluation et supprimez toutes les liaisons ou tous les pods que vous avez créés.
Consignez précisément les rôles et les liaisons qui ont permis l’élévation afin qu’ils puissent être renforcés.
Vérification rapide
Vérifiez votre compréhension de RBAC.
Récapitulatif
Vous avez appris comment RBAC et les comptes de service régissent l’accès au cluster et peuvent le compromettre.
- RBAC associe les sujets à des verbes applicables aux ressources ; le rôle d’administrateur du cluster donne un contrôle total.
- Les pods montent des jetons SA ;
auth can-irévèle leur portée. - La création de pods, les liaisons, la lecture des secrets et l’usurpation permettent une élévation de privilèges.
- Les comptes appliquant le moindre privilège et la désactivation du montage automatique renforcent le cluster.
Ensuite : sécurité des pods et politiques réseau.
Apprends Cyber Security Academy avec un tuteur IA — gratuit
Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.
- Cours
- 76
- Leçons
- 303
Questions Fréquemment Posées
La leçon « RBAC et comptes de service » est-elle gratuite ?
Oui — le texte complet de « RBAC et comptes de service » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Cyber Security Academy, passe à CoddyKit PRO. Le cours Cyber Security Academy comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « RBAC et comptes de service » ?
Sécuriser l’accès aux grappes. Tu pratiques Cyber Security Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Cyber Security Academy ?
Aucune expérience préalable n'est requise. Cyber Security Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.
Combien de temps prend la leçon « RBAC et comptes de service » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Cyber Security Academy ?
Oui. Chaque leçon Cyber Security Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Modèle de menace de Kubernetes
- RBAC et comptes de service
- Sécurité des pods et politiques réseau
- Sécuriser la chaîne d’approvisionnement et les secrets