GSP493

Présentation

Cet atelier couvre l'utilisation et le débogage du contrôle des accès basé sur les rôles (RBAC, Role-Based Access Control) dans un cluster Kubernetes Engine.

Les définitions des ressources RBAC sont normalisées sur toutes les plates-formes Kubernetes, mais vous devez bien comprendre leur interaction avec les fournisseurs d'authentification et d'autorisation si vous recourez à un fournisseur cloud.

Le RBAC est un mécanisme de sécurité performant qui offre une grande flexibilité pour restreindre les opérations dans un cluster. Cet atelier aborde deux cas d'utilisation du contrôle des accès basé sur les rôles :

1. Attribution d'autorisations différentes à des personas utilisateur, en l'occurrence des propriétaires et des auditeurs.
2. Octroi d'un accès limité aux API pour une application qui s'exécute dans le cluster.

Compte tenu de sa flexibilité, le RBAC peut parfois donner lieu à des règles complexes. C'est pourquoi vous trouverez des procédures de dépannage dans le scénario 2.

Architecture

Cet atelier se concentre sur l'utilisation du RBAC dans un cluster Kubernetes Engine. Il montre comment accorder différents niveaux d'accès au cluster aux personas utilisateur. Vous allez provisionner deux comptes de service représentant des personas utilisateur et trois espaces de noms (dev, test et prod). Le persona "owner" (propriétaire) bénéficiera d'un accès en lecture/écriture aux trois espaces de noms, et le persona "auditor" (auditeur) d'un accès en lecture seule limité à l'espace de noms "dev".

Cet atelier a été créé par des ingénieurs de GKE Helmsman pour vous aider à mieux comprendre l'utilisation du contrôle des accès basé sur les rôles dans GKE. Vous pouvez voir cette démonstration sur GitHub. Nous vous invitons tous à enrichir nos ressources !

Préparation

Avant de cliquer sur le bouton "Démarrer l'atelier"

Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique vous permet de suivre les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Des identifiants temporaires vous sont fournis pour vous permettre de vous connecter à Google Cloud le temps de l'atelier.

Pour réaliser cet atelier :

• Vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome).

Remarque : Ouvrez une fenêtre de navigateur en mode incognito (recommandé) ou de navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le compte temporaire de participant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.

• Vous disposez d'un temps limité. N'oubliez pas qu'une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.

Remarque : Utilisez uniquement le compte de participant pour cet atelier. Si vous utilisez un autre compte Google Cloud, des frais peuvent être facturés à ce compte.

Démarrer l'atelier et se connecter à la console Google Cloud

1. Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, une boîte de dialogue s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la gauche, vous trouverez le panneau "Détails concernant l'atelier", qui contient les éléments suivants :

   • Le bouton "Ouvrir la console Google Cloud"
   • Le temps restant
   • Les identifiants temporaires que vous devez utiliser pour cet atelier
   • Des informations complémentaires vous permettant d'effectuer l'atelier

2. Cliquez sur Ouvrir la console Google Cloud (ou effectuez un clic droit et sélectionnez Ouvrir le lien dans la fenêtre de navigation privée si vous utilisez le navigateur Chrome).

   L'atelier lance les ressources, puis ouvre la page "Se connecter" dans un nouvel onglet.

   Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.

   Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.

3. Si nécessaire, copiez le nom d'utilisateur ci-dessous et collez-le dans la boîte de dialogue Se connecter.

   {{{user_0.username | "Username"}}}

   Vous trouverez également le nom d'utilisateur dans le panneau "Détails concernant l'atelier".

4. Cliquez sur Suivant.

5. Copiez le mot de passe ci-dessous et collez-le dans la boîte de dialogue Bienvenue.

   {{{user_0.password | "Password"}}}

   Vous trouverez également le mot de passe dans le panneau "Détails concernant l'atelier".

6. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis pour l'atelier. Ne saisissez pas ceux de votre compte Google Cloud. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.

7. Accédez aux pages suivantes :

   • Acceptez les conditions d'utilisation.
   • N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
   • Ne vous inscrivez pas à des essais sans frais.

Après quelques instants, la console Cloud s'ouvre dans cet onglet.

Remarque : Pour accéder aux produits et services Google Cloud, cliquez sur le menu de navigation ou saisissez le nom du service ou du produit dans le champ Recherche.

Activer Cloud Shell

Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud. Cloud Shell vous permet d'accéder via une ligne de commande à vos ressources Google Cloud.

1. Cliquez sur Activer Cloud Shell  en haut de la console Google Cloud.

2. Passez les fenêtres suivantes :

   • Accédez à la fenêtre d'informations de Cloud Shell.
   • Autorisez Cloud Shell à utiliser vos identifiants pour effectuer des appels d'API Google Cloud.

Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET : . Le résultat contient une ligne qui déclare l'ID_PROJET pour cette session :

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

3. (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

4. Cliquez sur Autoriser.

Résultat :

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Remarque : Pour consulter la documentation complète sur gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.

Définir votre région et votre zone

Certaines ressources Compute Engine sont hébergées dans des régions et des zones. Une région est un emplacement géographique spécifique où vous pouvez exécuter vos ressources. Chaque région se compose d'une ou plusieurs zones.

Pour en savoir plus et accéder à une liste complète des régions et zones disponibles, consultez la documentation sur les régions et les zones.

Exécutez la commande suivante pour définir la région et la zone associées à votre atelier (vous pouvez utiliser la région/zone qui vous convient le mieux) :

gcloud config set compute/region {{{project_0.default_region|REGION}}} gcloud config set compute/zone {{{project_0.default_zone|ZONE}}}

Tâche 1 : Vérifier le cluster

Vérifiez dans la console que le cluster pré-créé existe bien. Pour cela, accédez au menu de navigation > Kubernetes Engine > Clusters, puis cliquez sur le cluster "rbac-demo-cluster". Assurez-vous que l'ancienne autorisation est désactivée pour le nouveau cluster.

Tâche 2 : Scénario 1 - Attribution des autorisations par persona utilisateur

IAM : rôle

Un rôle nommé kube-api-ro-xxxxxxxx (où xxxxxxxx est une chaîne aléatoire) a été créé avec les autorisations ci-dessous dans le cadre de la configuration de Terraform dans iam.tf. Il s'agit des autorisations indispensables à un utilisateur ayant besoin d'accéder à l'API Kubernetes.

• container.apiservices.get
• container.apiservices.list
• container.clusters.get
• container.clusters.getCredentials

Simuler des utilisateurs

Trois comptes de service ont été créés correspondant aux utilisateurs tests suivants :

• admin dispose des autorisations d'administration du cluster et de toutes les ressources.
• owner (propriétaire) dispose d'un accès en lecture/écriture aux ressources communes du cluster.
• auditor (auditeur) dispose d'un accès en lecture seule, pour l'espace de noms dev uniquement.

1. Exécutez la commande suivante :

gcloud iam service-accounts list

Trois hôtes tests ont été provisionnés par le script Terraform. kubectl et gcloud ont été installés sur chaque nœud pour simuler un persona utilisateur différent.

• gke-tutorial-admin : kubectl et gcloud sont authentifiés en tant qu'administrateurs du cluster.
• gke-tutorial-owner : simule le compte propriétaire.
• gke-tutorial-auditor : simule le compte auditeur.

2. Exécutez la commande suivante :

gcloud compute instances list

Résultat :

NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS rbac-demo-cluster-default-pool-a9cd3468-4vpc {{{project_0.default_zone|ZONE}}} n1-standard-1 10.0.96.5 RUNNING rbac-demo-cluster-default-pool-a9cd3468-b47f {{{project_0.default_zone|ZONE}}} n1-standard-1 10.0.96.6 RUNNING rbac-demo-cluster-default-pool-a9cd3468-rt5p {{{project_0.default_zone|ZONE}}} n1-standard-1 10.0.96.7 RUNNING gke-tutorial-auditor {{{project_0.default_zone|ZONE}}} f1-micro 10.0.96.4 35.224.148.28 RUNNING gke-tutorial-admin {{{project_0.default_zone|ZONE}}} f1-micro 10.0.96.3 35.226.237.142 RUNNING gke-tutorial-owner {{{project_0.default_zone|pZONE}}} f1-micro 10.0.96.2 35.194.58.130 RUNNING

Créer des règles RBAC

Pour créer les espaces de noms, les rôles et les liaisons de rôles (Namespaces, Roles et RoleBindings), connectez-vous à l'instance d'administration (Admin) et appliquez le fichier manifeste rbac.yaml.

1. Connectez-vous à l'instance "Admin" via SSH :

gcloud compute ssh gke-tutorial-admin Remarque : Ignorez le message d'erreur sur le plug-in d'authentification GCP.

Les versions existantes de kubectl et les clients Kubernetes personnalisés contiennent du code spécifique au fournisseur pour gérer l'authentification entre le client et Google Kubernetes Engine. À partir de la version 1.26, ce code ne sera plus inclus dans kubectl Open Source. Les utilisateurs de GKE devront télécharger et utiliser un plug-in d'authentification distinct pour générer des jetons spécifiques à GKE. Ce nouveau binaire, gke-gcloud-auth-plugin, exploite le mécanisme des plug-ins d'identification Kubernetes client-go pour étendre l'authentification de kubectl à GKE. Pour en savoir plus, vous pouvez consulter cette documentation.

Pour que kubectl utilise le nouveau plug-in binaire pour l'authentification plutôt que le code par défaut spécifique au fournisseur, procédez comme décrit ci-dessous.

2. Une fois connecté, exécutez la commande suivante pour installer gke-gcloud-auth-plugin sur la VM :

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin

3. Définissez export USE_GKE_GCLOUD_AUTH_PLUGIN=True dans ~/.bashrc :

echo "export USE_GKE_GCLOUD_AUTH_PLUGIN=True" >> ~/.bashrc

4. Exécutez la commande suivante :

source ~/.bashrc

5. Exécutez la commande suivante pour forcer la mise à jour de la configuration de ce cluster vers la configuration utilisant le plug-in d'identification Client-go.

gcloud container clusters get-credentials rbac-demo-cluster --zone {{{project_0.default_zone|ZONE}}}

Si l'opération réussit, le message suivant doit s'afficher :

Kubeconfig entry generated for dev-cluster.

Vous pouvez désormais utiliser les commandes kubectl standards sur l'hôte bastion pour le cluster que vous venez de créer.

6. Créez les espaces de noms, les rôles et les liaisons :

kubectl apply -f ./manifests/rbac.yaml

Résultat :

namespace/dev created namespace/prod created namespace/test created role.rbac.authorization.k8s.io/dev-ro created clusterrole.rbac.authorization.k8s.io/all-rw created clusterrolebinding.rbac.authorization.k8s.io/owner-binding created rolebinding.rbac.authorization.k8s.io/auditor-binding created

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer les règles RBAC

Gérer les ressources en tant que propriétaire

1. Ouvrez un autre terminal Cloud Shell en cliquant sur + en haut de la fenêtre du terminal.

Vous allez maintenant vous connecter à l'instance "owner" via SSH et créer un déploiement simple dans chaque espace de noms.

2. Connectez-vous à l'instance "owner" via SSH :

gcloud compute ssh gke-tutorial-owner Remarque : Ignorez le message d'erreur sur le plug-in d'authentification GCP.

3. Lorsque vous êtes invité à indiquer la zone, saisissez n de manière à utiliser la zone par défaut.

4. Installez gke-gcloud-auth-plugin :

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin echo "export USE_GKE_GCLOUD_AUTH_PLUGIN=True" >> ~/.bashrc source ~/.bashrc gcloud container clusters get-credentials rbac-demo-cluster --zone {{{project_0.default_zone|ZONE}}}

5. Créez un serveur dans chaque espace de noms. D'abord dans dev :

kubectl create -n dev -f ./manifests/hello-server.yaml

Résultat :

service/hello-server created deployment.apps/hello-server created

6. Ensuite, dans prod :

kubectl create -n prod -f ./manifests/hello-server.yaml

Résultat :

service/hello-server created deployment.apps/hello-server created

7. Enfin, dans test :

kubectl create -n test -f ./manifests/hello-server.yaml

Résultat :

service/hello-server created deployment.apps/hello-server created

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer un serveur dans chaque espace de noms

En tant que propriétaire, vous pouvez également afficher tous les pods.

• Sur l'instance "owner", affichez la liste de tous les pods hello-server de tous les espaces de noms en exécutant la commande suivante :

kubectl get pods -l app=hello-server --all-namespaces

Résultat :

NAMESPACE NAME READY STATUS RESTARTS AGE dev hello-server-6c6fd59cc9-h6zg9 1/1 Running 0 6m prod hello-server-6c6fd59cc9-mw2zt 1/1 Running 0 44s test hello-server-6c6fd59cc9-sm6bs 1/1 Running 0 39s

Afficher les ressources en tant qu'auditeur

Vous allez maintenant ouvrir un autre terminal, vous connecter à l'instance "auditor" via SSH et tenter d'afficher tous les espaces de noms.

1. Ouvrez un autre terminal Cloud Shell en cliquant sur + en haut de la fenêtre du terminal.

2. Connectez-vous à l'instance "auditor" via SSH :

gcloud compute ssh gke-tutorial-auditor Remarque : Ignorez le message d'erreur sur le plug-in d'authentification GCP.

3. Lorsque vous êtes invité à indiquer la zone, saisissez n de manière à utiliser la zone par défaut.

4. Installez gke-gcloud-auth-plugin :

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin echo "export USE_GKE_GCLOUD_AUTH_PLUGIN=True" >> ~/.bashrc source ~/.bashrc gcloud container clusters get-credentials rbac-demo-cluster --zone {{{project_0.default_zone|ZONE}}}

5. Sur l'instance "auditor", affichez la liste de tous les pods hello-server de tous les espaces de noms avec la commande suivante :

kubectl get pods -l app=hello-server --all-namespaces

Un message d'erreur semblable à celui-ci devrait apparaître :

Error from server (Forbidden): pods is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot list pods at the cluster scope: Required "container.pods.list" permission

Cette erreur indique que vous ne disposez pas des autorisations nécessaires. Le rôle auditor est autorisé uniquement à afficher les ressources de l'espace de noms dev. Donc, vous devrez spécifier l'espace de noms pour afficher les ressources.

Essayez à présent d'afficher les pods dans l'espace de noms dev.

6. Sur l'instance "auditor", exécutez la commande suivante :

kubectl get pods -l app=hello-server --namespace=dev

Résultat :

NAME READY STATUS RESTARTS AGE hello-server-6c6fd59cc9-h6zg9 1/1 Running 0 13m

7. Essayez d'afficher les pods de l'espace de noms "test" :

kubectl get pods -l app=hello-server --namespace=test

Résultat :

Error from server (Forbidden): pods is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot list pods in the namespace "test": Required "container.pods.list" permission.

8. Essayez d'afficher les pods de l'espace de noms "prod" :

kubectl get pods -l app=hello-server --namespace=prod

Résultat :

Error from server (Forbidden): pods is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot list pods in the namespace "prod": Required "container.pods.list" permission.

Enfin, vérifiez que l'auditeur dispose bien d'un accès en lecture seule en essayant de créer et de supprimer un déploiement dans l'espace de noms "dev".

9. Sur l'instance "auditor", tentez de créer un déploiement :

kubectl create -n dev -f manifests/hello-server.yaml

Résultat :

Error from server (Forbidden): error when creating "manifests/hello-server.yaml": services is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot create services in the namespace "dev": Required "container.services.create" permission. Error from server (Forbidden): error when creating "manifests/hello-server.yaml": deployments.extensions is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot create deployments.extensions in the namespace "dev": Required "container.deployments.create" permission.

10. Sur l'instance "auditor", essayez de supprimer le déploiement :

kubectl delete deployment -n dev -l app=hello-server

Résultat :

Error from server (Forbidden): deployments.extensions "hello-server" is forbidden: User "gke-tutorial-auditor@myproject.iam.gserviceaccount.com" cannot update deployments.extensions in the namespace "dev": Required "container.deployments.update" permission.

Tâche 3 : Scénario 2 - Attribution des autorisations d'API à une application du cluster

Dans ce scénario, vous allez suivre le processus de déploiement d'une application qui nécessite un accès à l'API Kubernetes. Vous allez également configurer des règles RBAC et résoudre des problèmes liés à des cas d'utilisation courants.

Déployer l'exemple d'application

L'exemple d'application s'exécutera en tant que pod unique pour récupérer périodiquement tous les pods de l'espace de noms par défaut à partir du serveur d'API et appliquer une étiquette de code temporel à chacun d'eux.

1. Depuis l'instance admin (il devrait s'agir de votre premier onglet Cloud Shell), déployez l'application pod-labeler. Cette opération déploie également un Role, un ServiceAccount et un RoleBinding pour le pod :

kubectl apply -f manifests/pod-labeler.yaml

Résultat :

role.rbac.authorization.k8s.io/pod-labeler created serviceaccount/pod-labeler created rolebinding.rbac.authorization.k8s.io/pod-labeler created deployment.apps/pod-labeler created

Cliquez sur Vérifier ma progression pour valider l'objectif. Déployer l'exemple d'application

Diagnostiquer une erreur de configuration RBAC

À présent, vérifiez l'état du pod. Une fois la création du conteneur terminée, celui-ci affiche une erreur. Analysez cette erreur en examinant les événements et les journaux des pods.

1. Sur l'instance admin, vérifiez l'état du pod :

kubectl get pods -l app=pod-labeler

Résultat :

NAME READY STATUS RESTARTS AGE pod-labeler-6d9757c488-tk6sp 0/1 Error 1 1m

2. Sur l'instance admin, affichez le flux d'événements du pod en exécutant la commande suivante :

kubectl describe pod -l app=pod-labeler | tail -n 20

Vous devriez obtenir le résultat suivant :

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 7m35s default-scheduler Successfully assigned default/pod-labeler-5b4bd6cf9-w66jd to gke-rbac-demo-cluster-default-pool-3d348201-x0pk Normal Pulling 7m34s kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk pulling image "gcr.io/pso-examples/pod-labeler:0.1.5" Normal Pulled 6m56s kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Successfully pulled image "gcr.io/pso-examples/pod-labeler:0.1.5" Normal Created 5m29s (x5 over 6m56s) kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Created container Normal Pulled 5m29s (x4 over 6m54s) kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Container image "gcr.io/pso-examples/pod-labeler:0.1.5" already present on machine Normal Started 5m28s (x5 over 6m56s) kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Started container Warning BackOff 2m25s (x23 over 6m52s) kubelet, gke-rbac-demo-cluster-default-pool-3d348201-x0pk Back-off restarting failed container

3. Sur l'instance admin, exécutez la commande suivante pour consulter les journaux du pod :

kubectl logs -l app=pod-labeler

Résultat :

Attempting to list pods Traceback (most recent call last): File "label_pods.py", line 13, in ret = v1.list_namespaced_pod("default",watch=False) File "build/bdist.linux-x86_64/egg/kubernetes/client/apis/core_v1_api.py", line 12310, in list_namespaced_pod File "build/bdist.linux-x86_64/egg/kubernetes/client/apis/core_v1_api.py", line 12413, in list_namespaced_pod_with_http_info File "build/bdist.linux-x86_64/egg/kubernetes/client/api_client.py", line 321, in call_api File "build/bdist.linux-x86_64/egg/kubernetes/client/api_client.py", line 155, in __call_api File "build/bdist.linux-x86_64/egg/kubernetes/client/api_client.py", line 342, in request File "build/bdist.linux-x86_64/egg/kubernetes/client/rest.py", line 231, in GET File "build/bdist.linux-x86_64/egg/kubernetes/client/rest.py", line 222, in request kubernetes.client.rest.ApiException: (403) Reason: Forbidden HTTP response headers: HTTPHeaderDict({'Date': 'Fri, 25 May 2018 15:33:15 GMT', 'Audit-Id': 'ae2a0d7c-2ab0-4f1f-bd0f-24107d3c144e', 'Content-Length': '307', 'Content-Type': 'application/json', 'X-Content-Type-Options': 'nosniff'}) HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"pods is forbidden: User \"system:serviceaccount:default:default\" cannot list pods in the namespace \"default\": Unknown user \"system:serviceaccount:default:default\"","reason":"Forbidden","details":{"kind":"pods"},"code":403}

Ce message d'erreur indique qu'il s'agit d'une erreur d'autorisations qui survient lorsque vous tentez de lister les pods via l'API.

4. L'étape suivante consiste à vérifier que vous utilisez le bon ServiceAccount.

Corriger le serviceAccountName

Si vous examinez la configuration du pod, vous pouvez voir qu'il utilise le compte de service par défaut, et non le compte de service personnalisé.

1. Sur l'instance admin, exécutez la commande suivante :

kubectl get pod -oyaml -l app=pod-labeler

Résultat :

restartPolicy: Always schedulerName: default-scheduler securityContext: fsGroup: 9999 runAsGroup: 9999 runAsUser: 9999 serviceAccount: default

Le fichier pod-labeler-fix-1.yaml contient le correctif de la spécification du modèle de déploiement :

# Fix 1, set the serviceAccount so RBAC rules apply serviceAccount: pod-labeler

Vous allez maintenant appliquer le correctif et observer la modification ainsi obtenue.

2. Sur l'instance admin, appliquez le correctif 1 en exécutant la commande suivante :

kubectl apply -f manifests/pod-labeler-fix-1.yaml

Résultat :

role.rbac.authorization.k8s.io/pod-labeler unchanged serviceaccount/pod-labeler unchanged rolebinding.rbac.authorization.k8s.io/pod-labeler unchanged deployment.apps/pod-labeler configured

3. Affichez la modification dans la configuration du déploiement :

kubectl get deployment pod-labeler -oyaml

Modifications visibles dans le résultat :

... restartPolicy: Always schedulerName: default-scheduler securityContext: {} serviceAccount: pod-labeler ...

Cliquez sur Vérifier ma progression pour valider l'objectif. Corriger le nom du compte de service

Diagnostiquer des droits d'accès insuffisants

Vérifiez à nouveau l'état de votre pod. Il génère encore une erreur, mais le message qui s'affiche est différent.

1. Sur l'instance admin, vérifiez l'état de votre pod :

kubectl get pods -l app=pod-labeler

Résultat :

NAME READY STATUS RESTARTS AGE pod-labeler-c7b4fd44d-mr8qh 0/1 CrashLoopBackOff 3 1m

Vous devrez peut-être exécuter à nouveau la commande précédente pour obtenir ce résultat.

2. Sur l'instance admin, consultez les journaux du pod :

kubectl logs -l app=pod-labeler

Résultat :

File "/usr/local/lib/python3.8/site-packages/kubernetes/client/rest.py", line 292, in PATCH return self.request("PATCH", url, File "/usr/local/lib/python3.8/site-packages/kubernetes/client/rest.py", line 231, in request raise ApiException(http_resp=r) kubernetes.client.rest.ApiException: (403) Reason: Forbidden HTTP response headers: HTTPHeaderDict({'Audit-Id': 'f6c67c34-171f-42f3-b1c9-833e00cedd5e', 'Content-Type': 'application/json', 'X-Content-Type-Options': 'nosniff', 'Date': 'Mon, 23 Mar 2020 16:35:18 GMT', 'Content-Length': '358'}) HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"pods \"pod-labeler-659c8c99d5-t96pw\" is forbidden: User \"system:serviceaccount:default:pod-labeler\" cannot patch resource \"pods\" in API group \"\" in the namespace \"default\"","reason":"Forbidden","details":{"name":"pod-labeler-659c8c99d5-t96pw","kind":"pods"},"code":403}

Vu que l'échec survient lors d'une opération PATCH, vous pouvez également voir l'erreur dans Stackdriver. Cela peut s'avérer utile lorsque les journaux de l'application ne donnent pas suffisamment de détails.

3. Dans la console, sélectionnez le menu de navigation. Ensuite, dans la section "Opérations", cliquez sur Journalisation.

4. Dans la boîte de dialogue du Générateur de requêtes, collez le code suivant et cliquez sur Exécuter la requête :

protoPayload.methodName="io.k8s.core.v1.pods.patch"

5. Cliquez sur la flèche vers le bas à côté d'un enregistrement de journal et examinez les détails.

Identifier le rôle et les autorisations de l'application

Utilisez la ClusterRoleBinding (liaison de rôle de cluster) pour trouver le rôle et les autorisations du ServiceAccount (compte de service).

1. Sur l'instance admin, examinez la définition de la rolebinding :

kubectl get rolebinding pod-labeler -oyaml

Résultat :

apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"name":"pod-labeler","namespace":"default"},"roleRef":{"apiGroup":"rbac.authorization.k8s.io","kind":"Role","name":"pod-labeler"},"subjects":[{"kind":"ServiceAccount","name":"pod-labeler"}]} creationTimestamp: "2020-03-23T16:29:05Z" name: pod-labeler namespace: default resourceVersion: "2886" selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/rolebindings/pod-labeler uid: 0e4d5be7-d986-40d0-af1d-a660f9aa4336 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pod-labeler subjects: - kind: ServiceAccount name: pod-labeler

La RoleBinding indique que vous devez examiner le rôle pod-labeler dans l'espace de noms par défaut. Vous voyez ici que le rôle inclut uniquement l'autorisation de lister les pods.

2. Sur l'instance admin, examinez la définition du rôle pod-labeler :

kubectl get role pod-labeler -oyaml

Résultat :

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"pod-labeler","namespace":"default"},"rules":[{"apiGroups":[""],"resources":["pods"],"verbs":["list"]}]} creationTimestamp: "2020-03-23T16:29:05Z" name: pod-labeler namespace: default resourceVersion: "2883" selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/roles/pod-labeler uid: c8191869-c7de-42c6-98fc-79a91d9b02a1 rules: - apiGroups: - "" resources: - pods verbs: - list

Comme l'application a besoin de l'autorisation PATCH, vous pouvez ajouter cette autorisation à la liste des "verbes" associés au rôle. C'est ce que vous allez faire dès maintenant.

Le fichier pod-labeler-fix-2.yaml contient la correction souhaitée dans la section rules/verbs :

rules: - apiGroups: [""] # "" refers to the core API group resources: ["pods"] verbs: ["list","patch"] # Fix 2: adding permission to patch (update) pods

Appliquez le correctif et affichez la configuration ainsi obtenue.

3. Sur l'instance admin, appliquez le correctif fix-2 :

kubectl apply -f manifests/pod-labeler-fix-2.yaml

Résultat :

role.rbac.authorization.k8s.io/pod-labeler configured serviceaccount/pod-labeler unchanged rolebinding.rbac.authorization.k8s.io/pod-labeler unchanged deployment.apps/pod-labeler unchanged

Cliquez sur Vérifier ma progression pour valider l'objectif. Identifier le rôle et les autorisations de l'application

4. Sur l'instance admin, affichez la modification obtenue :

kubectl get role pod-labeler -oyaml

Résultat :

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"pod-labeler","namespace":"default"},"rules":[{"apiGroups":[""],"resources":["pods"],"verbs":["list","patch"]}]} creationTimestamp: "2020-03-23T16:29:05Z" name: pod-labeler namespace: default resourceVersion: "8802" selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/default/roles/pod-labeler uid: c8191869-c7de-42c6-98fc-79a91d9b02a1 rules: - apiGroups: - "" resources: - pods verbs: - list - patch

Comme il se peut que l'application pod-labeler soit dans une boucle back-off, le moyen le plus rapide de tester le correctif consiste à arrêter le pod existant de sorte qu'un autre prenne sa place.

5. Sur l'instance admin, exécutez la commande suivante pour arrêter le pod existant et attendez que le contrôleur de déploiement le remplace :

kubectl delete pod -l app=pod-labeler

Résultat :

pod "pod-labeler-659c8c99d5-t96pw" deleted

Vérifier que la configuration est correcte

Enfin, vérifiez que la nouvelle application pod-labeler s'exécute et que l'étiquette "updated" (mise à jour) a été appliquée.

1. Sur l'instance admin, listez tous les pods et affichez leurs étiquettes :

kubectl get pods --show-labels

Résultat :

NAME READY STATUS RESTARTS NAME READY STATUS RESTARTS AGE LABELS pod-labeler-659c8c99d5-5qsmw 1/1 Running 0 31s app=pod-labeler,pod-template-hash=659c8c99d5,updated=1584982487.6428008

2. Affichez les journaux du pod pour vérifier qu'il n'y a plus d'erreurs :

kubectl logs -l app=pod-labeler

Résultat :

Attempting to list pods labeling pod pod-labeler-659c8c99d5-5qsmw labeling pod pod-labeler-659c8c99d5-t96pw ...

Ce qu'il faut retenir

• Les journaux du conteneur et du serveur d'API sont vos meilleures sources d'informations pour diagnostiquer les problèmes liés au contrôle des accès basé sur les rôles (RBAC).
• Utilisez les RoleBindings ou les ClusterRoleBindings pour déterminer le rôle précisant les autorisations accordées à un pod.
• Vous pouvez consulter les journaux du serveur d'API dans Stackdriver, sous la ressource Kubernetes.
• Les appels d'API ne sont pas tous consignés dans les journaux de Stackdriver. Les charges utiles fréquentes ou détaillées sont omises par la règle d'audit de Kubernetes dans Kubernetes Engine. La règle exacte diffère selon la version de Kubernetes que vous utilisez, mais vous pouvez la consulter dans le codebase Open Source.

Félicitations !

Vous avez découvert le contrôle des accès basé sur les rôles (RBAC) en attribuant différentes autorisations à des personas utilisateur et en accordant un accès limité aux API à une application exécutée dans le cluster.

Étapes suivantes et informations supplémentaires

• Configurer le contrôle des accès basé sur les rôles
• Créer des stratégies IAM
• Authentification des comptes de service Kubernetes
• Documentation Terraform

Formations et certifications Google Cloud

Les formations et certifications Google Cloud vous aident à tirer pleinement parti des technologies Google Cloud. Nos cours portent sur les compétences techniques et les bonnes pratiques à suivre pour être rapidement opérationnel et poursuivre votre apprentissage. Nous proposons des formations pour tous les niveaux, à la demande, en salle et à distance, pour nous adapter aux emplois du temps de chacun. Les certifications vous permettent de valider et de démontrer vos compétences et votre expérience en matière de technologies Google Cloud.

Dernière mise à jour du manuel : 24 février 2025

Dernier test de l'atelier : 24 février 2025

Copyright 2024 Google LLC. Ce logiciel est distribué tel quel, sans garantie ni représentation pour quelque utilisation ou fin que ce soit. Votre utilisation de ce logiciel est sujette à l'accord conclu avec Google.