Introduction
Orchard Market a besoin d’un petit tableau de bord d’état pour ses applications de stands et de livraison. Le programme du tableau est prêt, mais son identité Kubernetes actuelle ne peut pas lire leurs Deployments. Donnez au tableau sa propre identité et uniquement les permissions nécessaires pour afficher les véritables nombres de réplicas souhaités, de réplicas disponibles et les images des modèles. Gardez l’espace de noms du personnel, les Secrets et les modifications des charges de travail hors de son accès.
Votre résultat est un tableau utilisable et un téléchargement CSV, ainsi que quatre manifestes enregistrés décrivant son identité, deux autorisations par espace de noms et le choix d’identité de la charge de travail. Le tableau effectue de véritables requêtes HTTPS vers le cluster préparé. Il n’a aucune donnée statique de réussite à substituer lorsque l’accès échoue.
Vous devez déjà connaître les chemins de base du terminal, les bases de YAML, les espaces de noms, les Pods, les Deployments, les Services et les labels. Ce lab explique les ServiceAccounts, les Roles, les RoleBindings et le client fourni avant de les utiliser. Un véritable cluster Kubernetes à un seul nœud, le tableau, des données d’application synthétiques et l’outil de diagnostic sont préparés. Vous n’installez pas le cluster, ne construisez pas d’image, ne programmez pas le client et ne copiez pas de jetons. La durée est une estimation de l’auteur incluant la lecture et les erreurs courantes, pas un temps de réalisation mesuré auprès de débutants.
Créer une identité dédiée au tableau
Dans cette étape, vous lirez la véritable identité initiale du tableau et enregistrerez un ServiceAccount dédié sans encore lui accorder l’accès aux applications.
Commencez dans l’onglet Board. Orchard Market doit afficher A clear view of the working day., les groupes Market stalls et Market delivery, et Access denied · API 403 pour les deux groupes. C’est le problème initial attendu. Le résultat complet affichera catalogue avec 2 réplicas souhaités et 2 disponibles, checkout avec 1 et 1, pickup avec 1 et 1 et receipts avec 0 et 0. Les quatre utilisent l’image de modèle préparée python:3.12-alpine. L’archive des reçus est volontairement réduite à zéro réplica.
Les trois champs principaux répondent à des questions différentes. Desired replicas est le nombre déclaré dans un Deployment. Available replicas est le nombre établi par le contrôleur après les contrôles de préparation et son temps minimal de préparation. Template image est l’image demandée par le modèle du Deployment ; pendant une mise à jour, elle ne prouve pas que chaque Pod existant utilise déjà cette image. Développez What these fields mean, lisez l’explication, puis repliez-la. Ce sont des observations du contrôleur, pas des contrôles de disponibilité des sites clients.
Choisissez Access details. La valeur Read as vient de l’API et se termine initialement par market-board:default. Le tableau indique la portée de permissions prévue ; il n’affirme pas que l’accès a déjà été accordé. Utilisez Back to status board, puis passez à Workspace.
Le terminal démarre dans /home/labex/project/status-board. pwd affiche votre répertoire de travail, ls liste ses entrées et cd avec un chemin absolu permet d’y revenir si vous avez changé de répertoire :
pwd
ls
cd /home/labex/project/status-board
Vous devez trouver scope.json, starter et tools. cat affiche le fichier de périmètre préparé. Celui-ci utilise JSON (JavaScript Object Notation), un format texte de valeurs nommées et de listes, pour enregistrer les véritables espaces de noms, l’identité et les noms d’applications :
cat scope.json
Le tableau s’exécute dans market-board, tandis que ses données d’application approuvées se trouvent dans market-stalls et market-delivery. market-office est exclu. --context=labex-v135 sélectionne le cluster préparé ; -n sélectionne un espace de noms. Les identifiants d’opérateur existants de Workspace permettent d’examiner et de configurer ces objets du cours. Ce ne sont pas les identifiants du tableau. Examinez les véritables Deployments cibles en tant que cet opérateur :
kubectl --context=labex-v135 get deployments -n market-stalls
kubectl --context=labex-v135 get deployments -n market-delivery
Lisez les noms et les résultats souhaités/disponibles, y compris l’archive des reçus à zéro réplica souhaité. Les objets sous-jacents existent même si le tableau ne peut pas les lire. Une réussite depuis ce terminal d’opérateur ne prouve pas l’accès d’un processus dans le Pod du tableau.
Un ServiceAccount est une identité d’API Kubernetes limitée à un espace de noms pour une charge de travail, pas un utilisateur Linux ni un visiteur du navigateur. Le Deployment préparé du tableau sélectionne initialement le ServiceAccount default. describe présente la configuration de l’objet en sections lisibles :
kubectl --context=labex-v135 describe deployment status-board -n market-board
Repérez le ServiceAccount sélectionné dans son modèle de Pod. Un Pod reçoit un identifiant projeté pour ce compte. Le client préparé le lit en interne et valide le certificat du serveur API avec l’autorité de certification fournie ; il n’affiche jamais cet identifiant et n’utilise pas votre kubeconfig d’opérateur. Vous configurez l’identité et les permissions au lieu d’implémenter la gestion des identifiants.
Le programme fourni ./tools/board-test exécute ce client dans le Pod actuel du tableau. Le préfixe ./ signifie que l’outil se trouve dans ce répertoire de travail. Son premier argument sélectionne une opération de diagnostic enseignée. identity demande à l’API comment elle a authentifié ce véritable identifiant :
./tools/board-test identity
Vous devez obtenir username égal à system:serviceaccount:market-board:default, avec le pod_uid actuel. La valeur http_status de 201 signifie que l’API a répondu à cette demande d’examen de sa propre identité. Cet examen n’est pas un objet persistant du cluster, ne change pas les permissions et ne crée pas de Deployment. Aucun jeton n’est affiché. Un processus de tableau prêt et une identité confirmée peuvent encore ne pas avoir accès aux données d’application.
Créez votre répertoire de publication. mkdir -p le crée si nécessaire et préserve un répertoire existant. Dans la commande suivante, > redirige la sortie vers votre fichier modifiable. Le marqueur YAML entre apostrophes garde le texte littéral jusqu’au marqueur final sur sa propre ligne. Répéter la commande écrase uniquement ce fichier de publication :
mkdir -p release
cat > release/identity.yaml <<'YAML'
apiVersion: v1
kind: ServiceAccount
metadata:
name: market-reader
namespace: market-board
YAML
Lisez votre fichier, puis appliquez-le. apply -f lit le manifeste nommé et crée ou met à jour son objet :
cat release/identity.yaml
kubectl --context=labex-v135 apply -f release/identity.yaml
kubectl --context=labex-v135 get serviceaccount market-reader -n market-board
L’identité dédiée existe maintenant. Un Secret de jeton de longue durée n’est pas automatiquement requis : Kubernetes projette un identifiant lié dans un Pod lorsque ce Pod utilise l’identité. Créer ce ServiceAccount seul n’accorde pas l’accès aux Deployments et ne change pas l’identité du tableau en cours d’exécution. Gardez le compte default d’origine inchangé.
Si un chemin est mal saisi, utilisez les commandes déjà montrées pwd, ls et cd absolu, puis répétez l’opération qui a échoué. Pour une erreur YAML, lisez votre fichier modifiable, comparez l’indentation à l’exemple complet, réécrivez-le et appliquez-le à nouveau. Gardez scope.json, le fichier de départ, les outils, les espaces de noms, les applications et les données d’origine inchangés. Vous modifierez uniquement les manifestes de publication indiqués et leurs objets d’identité/RBAC nommés, ainsi que le ServiceAccount sélectionné du Deployment du tableau.
Connecter le premier espace de noms
Dans cette étape, vous accorderez deux opérations de lecture dans l’espace de noms des stands, puis ferez réellement utiliser l’identité dédiée par un nouveau Pod du tableau.
Commencez dans Workspace, dans /home/labex/project/status-board. RBAC dans Kubernetes signifie contrôle d’accès fondé sur les rôles. Un Role définit des permissions dans un espace de noms. Un RoleBinding relie le Role de cet espace de noms à une identité. Des noms identiques ne suffisent pas à établir cette liaison.
Le tableau a besoin de list pour lire une collection de Deployments et de get pour ouvrir un Deployment individuel. Les Deployments appartiennent au groupe API apps ; la règle utilise apps, sans /v1. watch demanderait un flux de changements, que ce tableau n’utilise pas. Aucun verbe d’écriture ni accès aux Secrets n’est nécessaire. Gardez les deux verbes de lecture disponibles pour tous les Deployments de chaque espace de noms approuvé. Omettez resourceNames, le champ de règle facultatif qui limite la permission à des ressources nommées. Le roleRef.apiGroup de la liaison identifie l’API RBAC, rbac.authorization.k8s.io ; il diffère du groupe apps contenant les Deployments autorisés par le Role.
Enregistrez un Role et sa liaison dans un même manifeste. Le séparateur --- commence un second document YAML. Le metadata.namespace de la liaison est le lieu où la permission s’applique, tandis que subjects.namespace est le lieu où le ServiceAccount existe. Ici, ils sont délibérément différents :
cat > release/first-access.yaml <<'YAML'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-reader
namespace: market-stalls
rules:
- apiGroups: [apps]
resources: [deployments]
verbs: [get, list]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: board-reader
namespace: market-stalls
subjects:
- kind: ServiceAccount
name: market-reader
namespace: market-board
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: deployment-reader
YAML
Lisez et appliquez les deux objets, puis examinez la liaison interprétée :
cat release/first-access.yaml
kubectl --context=labex-v135 apply -f release/first-access.yaml
kubectl --context=labex-v135 describe role deployment-reader -n market-stalls
kubectl --context=labex-v135 describe rolebinding board-reader -n market-stalls
Vous devez trouver uniquement get et list pour les Deployments. Suivez roleRef vers le Role dans market-stalls, et le sujet vers market-reader dans market-board. La liaison ne crée pas un second ServiceAccount dans l’espace de noms cible.
Le tableau en cours d’exécution utilise toujours default. L’opération list de l’outil de diagnostic demande la véritable collection de Deployments avec l’identifiant actuel de ce Pod. Une lecture interdite renvoie http_status: 403 et un code de sortie de commande non nul ; c’est attendu avant de changer l’identité de la charge de travail :
./tools/board-test list market-stalls
La nouvelle permission appartient à market-reader, pas à default. Ne corrigez pas cela en accordant l’accès au compte default. Sélectionnez le compte dédié dans une copie enregistrée du Deployment préparé du tableau.
Lisez d’abord tout le fichier de départ. Il contient l’image existante, la source montée, le contrôle de santé, le nombre de réplicas et les autres paramètres à préserver :
cat starter/board.yaml
kubectl set serviceaccount change l’identité sélectionnée. --local transforme ce fichier d’entrée sans l’appliquer au cluster. -f nomme l’entrée, -o yaml écrit un manifeste YAML sur la sortie standard et le > déjà appris l’enregistre comme votre fichier de publication modifiable :
kubectl --context=labex-v135 set serviceaccount --local -f starter/board.yaml market-reader -o yaml > release/board.yaml
Lisez le résultat et confirmez que spec.template.spec.serviceAccountName vaut market-reader. Gardez tous les autres paramètres de l’application :
cat release/board.yaml
kubectl --context=labex-v135 apply -f release/board.yaml
Le ServiceAccount d’un Pod existant ne peut pas être modifié sur place. Mettre à jour le modèle de Pod du Deployment crée un nouveau Pod. rollout status attend la nouvelle charge de travail ; --timeout=120s limite l’attente :
kubectl --context=labex-v135 rollout status deployment/status-board -n market-board --timeout=120s
kubectl --context=labex-v135 get pods -n market-board
Vous devez trouver un Pod actuel du tableau prêt. Remplacer ce Pod du tableau est nécessaire ; les Pods des applications cibles ne changent pas. Relisez sa véritable identité authentifiée :
./tools/board-test identity
Vous devez obtenir system:serviceaccount:market-board:market-reader et un pod_uid différent de celui du Pod d’origine à identité default. Cela confirme l’identifiant du processus, plutôt que d’évaluer simplement une identité usurpée pour un test.
Les résultats de collection et de détail des Deployments incluent aussi generation, la version de l’état souhaité du Deployment, et observed_generation, la dernière version traitée par son contrôleur. La page de détail les nomme Deployment generation et Observed generation. Un contrôleur peut brièvement être en retard sur un changement souhaité. Ces champs ne comptent pas les requêtes des clients et ne démontrent pas la disponibilité du site.
Lisez la collection des stands et un Deployment individuel. get prend l’espace de noms suivi du nom du Deployment :
./tools/board-test list market-stalls
./tools/board-test get market-stalls catalogue
Vous devez obtenir http_status: 200, les deux Deployments de stands d’origine dans la collection et catalogue avec 2 réplicas souhaités et 2 disponibles dans le résultat individuel. Le uid identifie l’objet d’origine ; l’image du modèle reste python:3.12-alpine. Un Role d’espace de noms ne s’étend pas à l’espace de noms de livraison :
./tools/board-test list market-delivery
Vous devez obtenir API 403 et un état de commande non nul pour cette dernière commande. Passez à Board, utilisez Refresh view, ouvrez Inspect catalogue et lisez ses nombres souhaités/disponibles et Template image. Utilisez Back to status board. Les fiches des stands doivent fonctionner tandis que le groupe de livraison affiche encore Access denied · API 403. Ce résultat partiel est une preuve utile de la limite d’espace de noms.
Si Read as affiche encore l’identité précédente juste après un déploiement progressif, utilisez à nouveau Refresh view. Pour confirmer le Pod courant, passez à Workspace, répétez ./tools/board-test identity, puis revenez à Board et actualisez. Le routage du Service peut avoir besoin d’un court instant pour rattraper le déploiement ; n’accordez pas l’accès à l’ancienne identité pour masquer cette transition.
Comparez le véritable lecteur, les fiches de stands fonctionnelles et le groupe de livraison encore refusé dans cet exemple en fonctionnement :
Si le déploiement expire, revenez à Workspace et examinez le même Deployment et les mêmes Pods avec les commandes describe et get déjà montrées. Si une lecture est refusée de manière inattendue, comparez le Role, l’espace de noms du sujet du RoleBinding et l’identité de charge de travail sélectionnée. Corrigez uniquement votre fichier de publication, appliquez-le et répétez le déploiement ou la requête appropriés. Ne copiez pas d’identifiants d’opérateur, ne modifiez pas l’application et ne redémarrez pas la VM.
Le roleRef d’un RoleBinding est immuable. Si une faute antérieure a créé la nouvelle liaison board-reader de ce cours avec la mauvaise référence de Role, Kubernetes refusera de modifier cette référence sur place. Après l’avoir examinée et avoir corrigé release/first-access.yaml, recréez uniquement votre propre liaison nommée, puis appliquez le fichier enregistré corrigé :
kubectl --context=labex-v135 delete rolebinding board-reader -n market-stalls
kubectl --context=labex-v135 apply -f release/first-access.yaml
Ce sont des commandes de récupération conditionnelles, pas une suppression requise dans le parcours normal réussi. Ne supprimez pas les liaisons default ou de la plateforme et ne supprimez pas le Deployment d’origine du tableau ni les charges de travail cibles.
Étendre le tableau sans élargir sa mission
Dans cette étape, vous donnerez à la même identité les mêmes deux opérations de lecture dans l’espace de noms de livraison, puis vérifierez les résultats utiles et les limites protégées.
Commencez dans Workspace, dans /home/labex/project/status-board. Un second espace de noms nécessite ses propres Role et RoleBinding. Réutilisez le nom du Role là-bas, mais gardez le sujet dans market-board ; l’identité n’a pas déménagé :
cat > release/second-access.yaml <<'YAML'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-reader
namespace: market-delivery
rules:
- apiGroups: [apps]
resources: [deployments]
verbs: [get, list]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: board-reader
namespace: market-delivery
subjects:
- kind: ServiceAccount
name: market-reader
namespace: market-board
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: deployment-reader
YAML
cat release/second-access.yaml
kubectl --context=labex-v135 apply -f release/second-access.yaml
kubectl --context=labex-v135 describe rolebinding board-reader -n market-delivery
La liaison accorde ce Role cible à l’identité existante du tableau. Aucun déploiement supplémentaire du tableau n’est nécessaire, car le Pod actuel utilise déjà cette identité. Les autorisations RBAC s’additionnent ; changer l’ordre des fichiers n’introduit pas de règle de refus et ne retire pas une autorisation sans rapport.
Lisez les deux collections approuvées et un détail de livraison avec le véritable identifiant du tableau :
./tools/board-test list market-stalls
./tools/board-test list market-delivery
./tools/board-test get market-delivery pickup
Vous devez obtenir API 200 avec les objets et images d’origine. La collection de livraison inclut pickup avec 1 souhaité/1 disponible et receipts avec 0/0. Le Deployment à zéro réplica souhaité reste un véritable objet même s’il n’a aucun Pod en cours d’exécution. Préservez ce paramètre déclaré.
Vérifiez maintenant les données exclues. Un Secret Kubernetes stocke des valeurs de données nommées. Le staff-note préparé est une ressource synthétique d’exercice ; le tableau n’a aucune raison de le lire. L’opérateur peut confirmer que cet objet existe sans afficher ses valeurs :
kubectl --context=labex-v135 get secret staff-note -n market-stalls
Le propre identifiant du tableau doit toujours recevoir API 403 pour le troisième espace de noms et ce Secret. Les deux commandes suivantes doivent se terminer avec un état non nul :
./tools/board-test list market-office
./tools/board-test secret market-stalls staff-note
Un objet manquant, un échec de connexion ou une capture d’écran d’erreur n’équivalent pas à ce véritable refus d’autorisation. Le même client lit avec succès les cibles approuvées, tandis que les objets exclus existants restent intacts. Son fichier d’identifiant projeté ne lui donne pas accès à l’API des Secrets.
L’opération permission de l’outil demande à l’API si ce véritable identifiant peut effectuer une action. Elle n’effectue pas cette action. Les arguments sont l’espace de noms, le verbe et, le cas échéant, le nom du Deployment. L’examen non persistant renvoie http_status: 201 avec allowed: false pour chaque opération interdite ; l’outil renvoie un état non nul pour ce refus :
./tools/board-test permission market-stalls patch catalogue
./tools/board-test permission market-delivery delete pickup
./tools/board-test permission market-stalls create
Le tableau nécessite uniquement get et list ; aucun flux watch ni modification de charge de travail n’est autorisé. Gardez l’identité default et le RBAC d’origine de la plateforme inchangés. N’ajoutez pas de ClusterRole, de ClusterRoleBinding, de caractère générique, de sujet supplémentaire ni d’autorisation sur une autre ressource.
Passez à Board et utilisez Refresh view. Les deux groupes affichent maintenant leurs Deployments d’origine. Ouvrez Inspect pickup, lisez ses nombres et son image, puis utilisez Back to status board. Lisez la fiche receipts : Scaled to zero, 0 disponible, 0 souhaité. Ce n’est pas un substitut vide à une requête échouée.
Comparez le véritable lecteur, les quatre fiches de Deployments et l’archive visible à zéro réplica souhaité dans cet exemple terminé :
Choisissez Download CSV et ouvrez le véritable fichier téléchargé orchard-market-deployments.csv. Il a quatre lignes de données, une pour chaque Deployment d’origine, y compris l’archive des reçus. Comparez l’espace de noms, le nom du Deployment, les valeurs souhaitées/disponibles, l’image du modèle et l’état API à la page. C’est un nouvel export API, pas un exemple de réussite enregistré. Les téléchargements du navigateur et l’espace de travail du terminal sont des emplacements distincts ; il ne vous est pas demandé de copier le téléchargement dans l’espace de travail.
Choisissez Access details, confirmez la véritable valeur Read as et les deux portées d’espaces de noms prévues, puis utilisez Back to status board. Gardez chaque Deployment cible d’origine, identité de Pod/conteneur, source, image, donnée et label d’espace de noms. Préservez le Deployment et le Service d’origine du tableau ; seul son ServiceAccount sélectionné change. La publication réutilisable contient identity.yaml, first-access.yaml, second-access.yaml et board.yaml, correspondant à la véritable identité et aux permissions actives.
Si le second espace de noms reste refusé, revenez à Workspace, examinez sa liaison avec la commande describe montrée, comparez l’espace de noms du sujet et la référence du Role, corrigez votre fichier enregistré et appliquez-le à nouveau. Pour un mauvais roleRef immuable, utilisez la même récupération strictement limitée enseignée auparavant, cette fois uniquement pour votre nouvelle liaison de livraison :
kubectl --context=labex-v135 delete rolebinding board-reader -n market-delivery
kubectl --context=labex-v135 apply -f release/second-access.yaml
Exécutez ces commandes uniquement pour cette récupération précise. Si un accès exclu réussit de manière inattendue, examinez vos deux Roles enregistrés et leurs liaisons, retirez la permission involontaire dans ces objets et appliquez à nouveau. Une autorisation large n’est pas remplacée par un autre Role plus étroit. Ne modifiez pas les permissions de la plateforme ni l’application pour masquer une erreur. Les erreurs de chemin et de YAML utilisent la récupération enseignée précédemment, sans réinitialiser la VM.
L’outil terminé lit l’état des Deployments signalé par le contrôleur dans ce cluster préparé à un seul nœud. Il n’authentifie pas les visiteurs du tableau, ne lit pas les journaux ni les métriques des Pods et ne prouve pas la disponibilité en production. Son point de contrôle de préparation confirme uniquement que le processus du tableau peut servir ; les véritables résultats API établissent si les données d’application sont accessibles.
Résumé
Vous avez donné à un véritable consommateur interne au cluster son propre ServiceAccount, relié un Role limité à un espace de noms et un RoleBinding, puis fait utiliser cette identité par un nouveau Pod. Vous avez ensuite étendu le même travail de lecture à un second espace de noms approuvé sans autoriser l’accès aux données exclues ni les modifications des charges de travail.
Le tableau utilisable, le CSV actuel et les manifestes enregistrés relient l’identité, les permissions et les véritables résultats de l’API. Les réplicas souhaités, la disponibilité signalée par le contrôleur et les images des modèles restent des observations distinctes. Un refus de l’API reste indisponible, tandis qu’un Deployment volontairement à zéro réplica souhaité reste visible comme un véritable objet.
