Comptes de service et identité des charges de travail
Apprenez comment les comptes de service donnent leur propre identité aux pods, comment fonctionnent leurs jetons et comment leur accorder un accès selon le principe du moindre privilège.
Comptes de service et identité des charges de travail est une leçon DevOps Bootcamp gratuite sur CoddyKit. Ceci est la leçon 4 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 DevOps Bootcamp, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours DevOps Bootcamp comprend 4 leçons au total.
Identité des charges de travail
Les utilisateurs s’authentifient auprès de Kubernetes, mais les pods ont eux aussi besoin d’une identité pour pouvoir communiquer avec le serveur d’API en toute sécurité. Cette identité est un compte de service.
Qu’est-ce qu’un compte de service ?
Un ServiceAccount est un objet associé à un espace de noms qui représente l’identité d’une charge de travail. Chaque pod s’exécute sous l’identité d’un compte, et utilise default par défaut si vous n’en spécifiez pas.
apiVersion: v1
kind: ServiceAccount
metadata:
name: report-generator
namespace: analyticsAttribuer un compte de service à un pod
Définissez serviceAccountName dans la spécification du pod pour l’exécuter sous une identité précise.
apiVersion: v1
kind: Pod
metadata:
name: reporter
spec:
serviceAccountName: report-generator
containers:
- name: app
image: reporter:1.0Le jeton monté
Kubernetes monte dans le pod un jeton JWT de courte durée pour le compte de service, utilisé pour authentifier les appels à l’API.
# inside the Pod
cat /var/run/secrets/kubernetes.io/serviceaccount/tokenPourquoi le compte par défaut est risqué
Le compte default est partagé par tous les pods d’un espace de noms. Lui accorder des permissions exposerait excessivement toutes les charges de travail. Préférez un compte dédié par charge de travail.
Désactiver le montage automatique du jeton
Si un pod n’appelle jamais l’API, désactivez le montage du jeton afin de réduire la surface d’attaque.
apiVersion: v1
kind: Pod
metadata:
name: no-api-pod
spec:
automountServiceAccountToken: false
containers:
- name: app
image: myapp:1.0Accorder des permissions avec RBAC
Un compte de service n’a aucun pouvoir tant que vous ne l’avez pas associé à un rôle. Le sujet du RoleBinding est le compte de service.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: reporter-read
namespace: analytics
subjects:
- kind: ServiceAccount
name: report-generator
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioLe principe du moindre privilège en pratique
- Un compte de service par charge de travail
- N’accordez que les verbes et les ressources dont il a réellement besoin
- Limitez la portée à un espace de noms avec un rôle lorsque cela est possible, plutôt qu’à un ClusterRole
Jetons liés et projetés
Les jetons modernes sont projetés et liés à la durée de vie du pod, avec une courte période d’expiration. Ils sont renouvelés automatiquement, si bien qu’un jeton divulgué est bien moins dangereux que les anciens secrets de longue durée.
Identité des charges de travail dans le cloud
Les plateformes cloud associent un ServiceAccount Kubernetes à une identité IAM du cloud (par exemple IRSA sur AWS ou Workload Identity sur GKE), afin que les pods accèdent aux ressources cloud sans stocker d’identifiants statiques.
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123:role/report-roleVérifier les permissions
Utilisez kubectl auth can-i en usurpant l’identité du compte de service pour confirmer qu’il dispose exactement des accès attendus.
kubectl auth can-i list pods \
--as=system:serviceaccount:analytics:report-generator \
-n analyticsVérification rapide
Testez votre compréhension des comptes de service.
Récapitulatif
Vous avez appris qu’un ServiceAccount donne à un pod sa propre identité, soutenue par des jetons projetés de courte durée. Appliquez le principe du moindre privilège avec un compte dédié par charge de travail, accordez les accès au moyen de liaisons RBAC, désactivez le montage des jetons lorsqu’ils sont inutiles et associez les comptes à une identité IAM du cloud pour accéder aux ressources sans identifiants.
Questions Fréquemment Posées
La leçon « Comptes de service et identité des charges de travail » est-elle gratuite ?
Oui — le texte complet de « Comptes de service et identité des charges de travail » 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 DevOps Bootcamp, passe à CoddyKit PRO. Le cours DevOps Bootcamp comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Comptes de service et identité des charges de travail » ?
Apprenez comment les comptes de service donnent leur propre identité aux pods, comment fonctionnent leurs jetons et comment leur accorder un accès selon le principe du moindre privilège. Tu pratiques DevOps Bootcamp 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 DevOps Bootcamp ?
Aucune expérience préalable n'est requise. DevOps Bootcamp 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 4 sur 4.
Combien de temps prend la leçon « Comptes de service et identité des charges de travail » ?
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 DevOps Bootcamp ?
Oui. Chaque leçon DevOps Bootcamp 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
- Contrôle d’accès basé sur les rôles (RBAC)
- Politiques réseau pour l’isolation
- Normes de sécurité des Pods
- Comptes de service et identité des charges de travail