GSP493

Présentation

Cet atelier couvre l'utilisation et le débogage du contrôle des accès basé sur les rôles (RBAC) 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. Cliquez ici pour visualiser cette démonstration sur GitHub. Nous vous invitons tous à enrichir nos ressources !

Prérequis

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 vous-même les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Nous vous fournissons des identifiants temporaires pour 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/navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le temporaire étudiant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.

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

Remarque : Si vous possédez déjà votre propre compte ou projet Google Cloud, veillez à ne pas l'utiliser pour réaliser cet atelier afin d'éviter que des frais supplémentaires ne vous soient facturés.

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, un pop-up 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
   • 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. 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 inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue Se connecter. Cliquez sur Suivant.

4. Copiez le mot de passe inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue de bienvenue. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis dans le panneau de gauche. Ne saisissez pas vos identifiants Google Cloud Skills Boost. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.

5. 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 aux essais offerts.

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

Remarque : Vous pouvez afficher le menu qui contient la liste des produits et services Google Cloud en cliquant sur le menu de navigation en haut à gauche.

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.

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 YOUR_PROJECT_ID (VOTRE_ID_PROJET) pour cette session :

Your Cloud Platform project in this session is set to YOUR_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.

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

gcloud auth list

3. Cliquez sur Autoriser.

4. Vous devez à présent obtenir le résultat suivant :

Résultat :

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net 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 = <ID_Projet>

Exemple de résultat :

[core] project = qwiklabs-gcp-44776a13dea667a6 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, accédez à l'article Régions et 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 }}}

Cloner la démonstration

Clonez les ressources nécessaires pour réaliser cet atelier en exécutant la commande suivante :

gsutil cp gs://spls/gsp493/gke-rbac-demo.tar .
tar -xvf gke-rbac-demo.tar

Allez dans le répertoire extrait :

cd gke-rbac-demo

Provisionner le cluster Kubernetes Engine

À présent, appliquez la configuration Terraform.

À partir de la racine du projet, utilisez la commande make pour appliquer la configuration Terraform :

make create

La configuration de cette démonstration peut demander 10 à 15 minutes. Si aucune erreur ne s'affiche, la meilleure solution est de continuer à attendre. L'exécution de make create ne doit pas être interrompue.

Pendant la création des ressources, une fois que la création d'une instance google_compute_instance est lancée, vous pouvez suivre la progression dans la console en accédant à Compute Engine > VM instances (Compute Engine > Instances de VM). Utilisez le bouton Refresh (Actualiser) sur la page des instances de VM pour afficher les informations les plus récentes.

Une fois l'opération terminée, Terraform affiche un message indiquant que la création du cluster a réussi.

Vérifiez dans la console que le cluster a bien été créé. Accédez au menu de navigation > Kubernetes Engine > Clusters, puis cliquez sur le cluster qui vient d'être créé. Assurez-vous que l'ancienne autorisation est désactivée pour le nouveau cluster.

Cliquez sur Check my progress (Vérifier ma progression) pour vérifier l'objectif. Provisionner le cluster Kubernetes Engine

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 lors 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

Exécutez la commande suivante :

gcloud iam service-accounts list

(Résultat)

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 "owner" (propriétaire).
• gke-tutorial-auditor : simule le compte "auditor" (auditeur).

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    us-central1-a  n1-standard-1                10.0.96.5                    RUNNING
rbac-demo-cluster-default-pool-a9cd3468-b47f    us-central1-a  n1-standard-1                10.0.96.6                    RUNNING
rbac-demo-cluster-default-pool-a9cd3468-rt5p    us-central1-a  n1-standard-1                10.0.96.7                    RUNNING
gke-tutorial-auditor                            us-central1-a  f1-micro                     10.0.96.4    35.224.148.28    RUNNING
gke-tutorial-admin                              us-central1-a  f1-micro                     10.0.96.3    35.226.237.142   RUNNING
gke-tutorial-owner                              us-central1-a  f1-micro                     10.0.96.2    35.194.58.130    RUNNING

Créer des règles RBAC

Vous allez maintenant créer les espaces de noms, les rôles et les liaisons de rôle (Namespaces, Roles et RoleBindings) en vous connectant à l'instance admin et en appliquant le manifeste rbac.yaml.

Connectez-vous à l'instance admin via SSH :

gcloud compute ssh gke-tutorial-admin

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 Check my progress (Vérifier ma progression) pour vérifier l'objectif. Créer les règles RBAC

Gérer les ressources en tant que propriétaire

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 et créer un déploiement simple dans chaque espace de noms.

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

gcloud compute ssh gke-tutorial-owner

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

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

Ensuite, dans prod :

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

(Résultat)

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

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 Check my progress (Vérifier ma progression) pour vérifier 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 dans 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.

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

gcloud compute ssh gke-tutorial-auditor

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

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

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

Un message d'erreur semblable au suivant 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. 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

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.

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.

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.

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.

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, puis configurer des règles RBAC tout en dépannant certains cas d'utilisation courants.

Déployer l'exemple d'application

L'exemple d'application s'exécutera en tant que pod unique qui récupère périodiquement tous les pods de l'espace de noms par défaut à partir du serveur d'API et applique un libellé d'horodatage à chacun d'eux.

À partir de l'instance "admin", déployez l'application pod-labeler. Cette commande 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 Check my progress (Vérifier ma progression) pour vérifier 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.

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

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 obtenez 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

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}

Cette description indique qu'il s'agit d'une erreur d'autorisations qui survient lorsque vous tentez de répertorier les pods via l'API.

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, au lieu du compte de service personnalisé.

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 du modèle de spécification du déploiement :

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

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

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

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 Check my progress (Vérifier ma progression) pour vérifier l'objectif. Corriger le nom du compte de service

Diagnostiquer des droits d'accès insuffisants

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

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.

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.

Dans la console, sélectionnez le menu de navigation et, dans la section "Operations" (Opérations), cliquez sur Logging (Journalisation).

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

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

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

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

Utilisez le ClusterRoleBinding pour trouver le rôle et les autorisations du ServiceAccount.

Sur l'instance "admin", examinez la définition du 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

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

Sur l'instance "admin", examinez la définition du rôle de 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

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

Le fichier pod-labeler-fix-2.yaml contient la correction voulue dans sa 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.

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 Check my progress (Vérifier ma progression) pour vérifier l'objectif. Identifier le rôle et les autorisations de l'application

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 l'application pod-labeler est susceptible de redémarrer après un certain délai, le moyen le plus rapide de tester le correctif consiste à arrêter le pod existant de sorte qu'un autre prenne sa place.

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 a réussi

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

Sur l'instance "admin", répertoriez tous les pods et affichez leurs libellés :

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

Affichez les journaux du pod pour vérifier qu'aucune erreur n'a été consignée :

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 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 les versions de Kubernetes, mais vous pouvez la trouver dans le codebase Open Source.

Suppression

Lorsque vous avez terminé et que vous êtes prêt à éliminer les ressources créées, exécutez la commande suivante pour supprimer toutes les ressources :

Déconnectez-vous de l'hôte bastion en saisissant "exit".

Ensuite, exécutez la commande ci-dessous pour détruire l'environnement :

make teardown

(Résultat)

...snip...
google_service_account.auditor: Destruction complete after 0s
module.network.google_compute_subnetwork.cluster-subnet: Still destroying... (ID: us-east1/kube-net-subnet, 10s elapsed)
module.network.google_compute_subnetwork.cluster-subnet: Still destroying... (ID: us-east1/kube-net-subnet, 20s elapsed)
module.network.google_compute_subnetwork.cluster-subnet: Destruction complete after 26s
module.network.google_compute_network.gke-network: Destroying... (ID: kube-net)
module.network.google_compute_network.gke-network: Still destroying... (ID: kube-net, 10s elapsed)
module.network.google_compute_network.gke-network: Still destroying... (ID: kube-net, 20s elapsed)
module.network.google_compute_network.gke-network: Destruction complete after 25s

Destroy complete! Resources: 14 destroyed.

Cliquez sur Check my progress (Vérifier ma progression) pour vérifier l'objectif. Suppression

Résoudre les problèmes dans votre propre environnement

Le script d'installation échoue et affiche le message Permission denied (Autorisation refusée) lors de l'exécution de Terraform.

Les identifiants utilisés par Terraform ne fournissent pas les autorisations nécessaires pour créer des ressources dans les projets sélectionnés. Vérifiez que le compte répertorié dans gcloud config list possède les autorisations nécessaires pour créer des ressources. Si c'est le cas, générez à nouveau les identifiants par défaut de l'application à l'aide de gcloud auth application-default login.

Erreur d'empreinte non valide lors des opérations Terraform

Il peut arriver que Terraform signale une empreinte non valide au cours de la mise à jour de certaines ressources. Si le message d'erreur ci-dessous s'affiche, il suffit d'exécuter à nouveau la commande.

Félicitations

Terminer votre quête

Cet atelier d'auto-formation fait partie de la quête Qwiklabs Google Kubernetes Engine Best Practices: Security. Une quête est une série d'ateliers associés qui constituent une formation. Si vous terminez cette quête, vous obtiendrez le badge ci-dessus attestant de votre réussite. Vous pouvez rendre publics les badges que vous recevez et ajouter leur lien dans votre CV en ligne ou sur vos comptes de réseaux sociaux. Inscrivez-vous à cette quête pour obtenir immédiatement les crédits associés à cet atelier si vous l'avez suivi. Découvrez les autres quêtes Qwiklabs disponibles.

Atelier suivant

Continuez sur votre lancée en suivant l'atelier Sécurité de Google Kubernetes Engine : autorisation binaire, ou consultez ces suggestions :

• Renforcer la sécurité des configurations par défaut des clusters GKE

• Sécuriser les applications sur Kubernetes Engine : trois exemples

Étapes suivantes et informations supplémentaires

• Contrôle des accès basé sur les rôles dans Kubernetes Engine
• Intégration IAM dans Kubernetes Engine
• 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 : 17 mars 2022

Dernier test de l'atelier : 17 mars 2022

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.