Présentation

Vous allez contrôler l'accès à des clusters GKE à l'aide d'IAM. Vous allez créer une stratégie de sécurité des pods afin de limiter la création de pods privilégiés, puis la tester. Vous allez également effectuer une rotation des adresses IP et des identifiants.

Remarque : Pour cet atelier, vous allez utiliser le mode GKE Standard. Cet atelier explore les règles de sécurité pour les pods. Il n'est pas possible de créer des règles qui remplacent les paramètres de sécurité intégrés dans GKE Autopilot.

Objectifs

Dans cet atelier, vous allez apprendre à effectuer les tâches suivantes :

• Utiliser IAM pour contrôler l'accès à GKE
• Créer des stratégies de sécurité et les utiliser pour contrôler la création de pods
• Effectuer une rotation des adresses IP et des identifiants

Remarque : Pour cet atelier, Google Cloud Skills Boost vous fournit deux noms d'utilisateur, disponibles dans la boîte de dialogue "Détails de connexion".

Nous appellerons ces comptes Username 1 (Nom d'utilisateur 1) et Username 2 (Nom d'utilisateur 2).

Tâche 1 : Utiliser des rôles IAM pour accorder un accès administrateur à tous les clusters GKE du projet

Se connecter à la console Google Cloud en tant que premier utilisateur

1. Ouvrez une fenêtre de navigation privée et connectez-vous à la console Google Cloud comme d'habitude avec le compte Username 1 fourni. Remarque : Le même mot de passe est associé aux deux noms d'utilisateur.
2. Dans la barre de titre de la console Google Cloud, cliquez sur Activer Cloud Shell ().
3. Cliquez sur Continuer.

Une fois le provisionnement terminé, l'invite Cloud Shell s'affiche.

Remarque : Si vous vous déconnectez du compte Username 1, Google Cloud Skills Boost est susceptible de supprimer le compte Username 2. Vous devez donc rester connecté au compte Username 1 jusqu'à la fin de cet atelier.

Se connecter à la console Google Cloud en tant que deuxième utilisateur et explorer l'interface

1. Ouvrez un nouvel onglet dans la fenêtre de navigation privée.
2. Accédez à la page console.cloud.google.com.
3. Cliquez sur l'icône d'utilisateur située en haut à droite de l'écran, puis sur Ajouter un compte.
4. Connectez-vous à la console Google Cloud avec le compte Username 2 fourni. Rappelez-vous que le même mot de passe est associé aux deux noms d'utilisateur.

Remarque : Assurez-vous que vous vous trouvez bien dans l'onglet Username 2 de la console Google Cloud.

5. Une fois connecté via le compte Username 2, accédez au menu de navigation (), puis cliquez sur Kubernetes Engine > Clusters.

6. Assurez-vous que l'ID de projet de votre atelier est sélectionné en haut de la page.

Notez que l'option permettant de créer un cluster est désactivée.

Remarque : Le compte Username 2 peut actuellement accéder au projet, mais uniquement avec le rôle Lecteur. Toutes les ressources du projet lui sont donc accessibles, mais en lecture seule.

Accorder au compte Username 2 le rôle IAM d'administrateur GKE

Vous allez maintenant autoriser le compte Username 2 à créer un cluster GKE et à déployer des charges de travail. Pour ce faire, vous utiliserez des rôles primitifs afin d'accorder à cet utilisateur l'autorisation d'administrer tous les clusters GKE de ce projet et de gérer les ressources qui leur sont associées. Le compte Username 1 possède les droits de propriétaire du projet. Vous utiliserez ce compte pour accorder d'autres droits au compte Username 2.

1. Revenez à l'onglet du compte Username 1 dans la console Google Cloud.

Remarque : Assurez-vous que vous vous trouvez bien dans l'onglet Username 1 de la console Google Cloud.

2. Dans le menu de navigation (), cliquez sur IAM et administration > IAM.

3. Dans la console IAM, localisez la ligne qui correspond à Username 2, puis cliquez sur l'icône en forme de crayon située tout à droite de cette ligne pour modifier les autorisations de l'utilisateur.

4. Notez que le compte Username 2 dispose actuellement du rôle Lecteur, qui fournit un accès en lecture à toutes les ressources du projet.

5. Cliquez sur AJOUTER UN AUTRE RÔLE pour ajouter un autre rôle de la liste déroulante.

6. Dans la liste déroulante Sélectionnez un rôle, choisissez Kubernetes Engine > Kubernetes Engine Cluster Admin (Administrateur de clusters Kubernetes Engine).

7. Cliquez sur ENREGISTRER.

Remarque : Le compte Username 2 peut maintenant administrer tous les clusters GKE du projet et gérer les ressources qui leur sont associées.

Si ce niveau d'accès est trop permissif pour votre organisation, vous pouvez limiter les droits de l'utilisateur au sein des différents clusters GKE via le contrôle des accès basé sur le rôle Kubernetes.

Cliquez sur Vérifier ma progression pour valider l'objectif. Accorder au compte Username 2 le rôle IAM Administrateur de GKE

Tester l'accès du compte Username 2

Vous allez maintenant vérifier l'accès configuré en utilisant le compte Username 2 pour créer un cluster GKE.

1. Revenez à l'onglet du compte Username 2 dans la console Google Cloud.

Remarque : Assurez-vous que vous vous trouvez bien dans l'onglet Username 2 de la console Google Cloud.

2. Une fois connecté via le compte Username 2, accédez au menu de navigation (), puis cliquez sur Kubernetes Engine > Clusters.

L'option de création de cluster doit à présent être activée. Vous devrez peut-être actualiser l'onglet du compte Username 2 dans le navigateur Web pour voir les modifications.

3. Cliquez sur Créer pour commencer à créer un cluster GKE.

4. Cliquez sur Passer au mode standard, puis confirmez votre choix dans la fenêtre pop-up suivante.

Rappel : Pour cet atelier, vous devez utiliser le mode GKE Standard.

5. S'il n'est pas déjà défini sur cette valeur par défaut, définissez le nom du cluster sur standard-cluster-1.

6. Vérifiez qu'un cluster zonal est sélectionné, et non un cluster régional.

7. Si le cluster n'est pas déjà défini sur cette zone par défaut, sélectionnez la zone .

8. Conservez toutes les autres valeurs par défaut et cliquez sur Créer.

Le processus de provisionnement du cluster va commencer, mais il ne va pas aboutir.

Remarque : Cette étape de l'atelier n'est pas supposée réussir.

9. Cliquez sur l'icône de notification dans la barre d'outils en haut de l'écran pour afficher le message d'erreur.

Le compte Username 2 ne dispose pas encore de certains droits nécessaires pour déployer un cluster. Cela est dû au fait que GKE utilise des instances Google Cloud Compute Engine pour les nœuds.

Pour pouvoir déployer un cluster GKE, l'utilisateur doit également disposer du rôle iam.serviceAccountUser sur le compte de service Compute Engine par défaut.

Attribuer le rôle IAM ServiceAccountUser au compte Username 2

Vous allez maintenant utiliser IAM pour attribuer au compte Username 2 le rôle iam.serviceAccountUser. Le compte Username 2 pourra ainsi déployer un cluster GKE.

1. Revenez à l'onglet du compte Username 1 dans la console Google Cloud.

Remarque : Assurez-vous que vous vous trouvez bien dans l'onglet Username 1 de la console Google Cloud.

2. Dans le menu de navigation (), cliquez sur IAM et administration > Comptes de service.

3. Dans la console IAM, cliquez sur la ligne correspondant au compte de service Compute Engine par défaut pour le sélectionner.

4. Cliquez sur Autorisation pour ouvrir le panneau d'informations sur les autorisations.

5. Sur la page "Autorisation", cliquez sur Accorder l'accès.

Le panneau d'informations sur les autorisations s'ouvre dans la partie droite de la fenêtre.

6. Dans la zone Nouveaux comptes principaux, saisissez le nom d'utilisateur du compte Username 2. Vous pouvez copier ce nom depuis la page d'informations de l'atelier.
7. Dans la zone Sélectionnez un rôle, vérifiez que Comptes de service > Utilisateur du compte de service est sélectionné.
8. Cliquez sur Enregistrer.

Cliquez sur Vérifier ma progression pour valider l'objectif. Attribuer le rôle IAM Utilisateur du compte de service au compte Username 2

Vérifier que le compte Username 2 peut créer un cluster GKE

Vous allez maintenant vérifier l'accès configuré en utilisant le compte Username 2 pour créer un cluster GKE.

1. Revenez à l'onglet du compte Username 2 dans la console Google Cloud.

Remarque : Assurez-vous que vous vous trouvez bien dans l'onglet Username 2 de la console Google Cloud.

2. Une fois connecté via le compte Username 2, accédez au menu de navigation (), puis cliquez sur Kubernetes Engine > Clusters. Vous devrez peut-être actualiser votre navigateur Web.

3. Cliquez sur Créer pour commencer à créer un cluster GKE.

4. Cliquez sur Passer au mode standard, puis confirmez votre choix dans la fenêtre pop-up suivante.

5. S'il n'est pas déjà défini sur cette valeur par défaut, définissez le nom du cluster sur standard-cluster-1.

6. Vérifiez qu'un cluster zonal est sélectionné, et non un cluster régional.

7. Si le cluster n'est pas déjà défini sur cette zone par défaut, sélectionnez la zone .

8. Conservez toutes les autres valeurs par défaut et cliquez sur Créer.

Remarque : Le déploiement du cluster prend quelques minutes.

Cette fois, le cluster va bien se déployer.

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer un cluster GKE

Tâche 2 : Définir et utiliser l'admission de sécurité des pods

PodSecurity est un contrôleur d'admission Kubernetes qui vous permet d'appliquer les normes de sécurité des pods aux pods exécutés sur vos clusters GKE. Les normes de sécurité des pods sont des règles de sécurité prédéfinies qui répondent aux besoins de sécurité élevés des pods dans Kubernetes. Ces règles peuvent être de très permissives à très restrictives.

Dans cette tâche, vous allez créer une stratégie de sécurité des pods qui autorise la création de pods non privilégiés dans l'espace de noms par défaut du cluster. Les pods non privilégiés n'autorisent pas les utilisateurs à exécuter du code en tant qu'utilisateur root, et ont un accès limité aux périphériques de l'hôte.

Vous allez créer un ClusterRole qui pourra ensuite être utilisé dans une liaison de rôle qui associe la stratégie à des comptes ayant besoin de déployer des pods avec un accès non privilégié.

Il est possible d'accorder l'accès à la PSP intégrée aux utilisateurs ayant besoin de déployer des pods avec un accès privilégié. La PSP intégrée autorise les administrateurs à déployer des pods lorsque les stratégies de sécurité des pods sont activées.

Une fois ces composants configurés, vous activerez le contrôleur PodSecurityPolicy, qui applique ces stratégies. Vous testerez ensuite leur impact sur des utilisateurs disposant de droits différents.

Se connecter au cluster GKE

1. Revenez à l'onglet du compte Username 1 dans la console Google Cloud.

Remarque : Assurez-vous que vous vous trouvez bien dans l'onglet Username 1 de la console Google Cloud.

2. Dans Cloud Shell, saisissez la commande suivante afin de créer des variables d'environnement pour la zone Google Cloud et le nom du cluster qui ont servi à créer le cluster de cet atelier :

export my_zone={{{project_0.default_zone | ZONE }}} export my_cluster=standard-cluster-1

3. Configurez la complétion par tabulation dans l'outil de ligne de commande kubectl :

source <(kubectl completion bash)

4. Configurez l'accès à votre cluster pour kubectl :

gcloud container clusters get-credentials $my_cluster --zone $my_zone

Appliquer des normes de sécurité des pods à l'aide de PodSecurity

Pour utiliser le contrôleur d'admission PodSecurity, vous devez appliquer des normes spécifiques de sécurité des pods dans des modes spécifiques et à des espaces de noms spécifiques.

Créer des espaces de noms

Créez des espaces de noms dans votre cluster :

kubectl create ns baseline-ns kubectl create ns restricted-ns

Cette commande crée les espaces de noms suivants :

• baseline-ns : pour les charges de travail permissives
• restricted-ns : pour les charges de travail très restrictives

Utiliser des étiquettes pour appliquer les règles de sécurité

Appliquez les normes de sécurité des pods suivantes :

• baseline : appliquer à "baseline-ns" en mode avertissement
• restricted : appliquer à "restricted-ns" en mode forcé

kubectl label --overwrite ns baseline-ns pod-security.kubernetes.io/warn=baseline kubectl label --overwrite ns restricted-ns pod-security.kubernetes.io/enforce=restricted

Ces commandes permettent d'obtenir le résultat suivant :

• Les charges de travail de l'espace de noms "baseline-ns" qui enfreignent la règle "baseline" sont autorisées et le client affiche un message d'avertissement.
• Les charges de travail de l'espace de noms "restricted-ns" qui enfreignent la règle "restricted" sont refusées et GKE ajoute une entrée aux journaux d'audit.

Vérifiez que les étiquettes ont été ajoutées :

kubectl get ns --show-labels

Le résultat ressemble à ce qui suit :

baseline-ns Active 74s kubernetes.io/metadata.name=baseline-ns,pod-security.kubernetes.io/warn=baseline restricted-ns Active 18s kubernetes.io/metadata.name=restricted-ns,pod-security.kubernetes.io/enforce=restricted default Active 57m kubernetes.io/metadata.name=default kube-public Active 57m kubernetes.io/metadata.name=kube-public kube-system Active 57m kubernetes.io/metadata.name=kube-system

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer les espaces de noms et les étiquettes

Tester les règles configurées

Pour vérifier que le contrôleur d'admission PodSecurity fonctionne comme prévu, déployez une charge de travail qui ne respecte pas les règles "baseline" et "restricted" sur les deux espaces de noms. L'exemple de fichier manifeste suivant déploie un conteneur nginx qui permet l'élévation des privilèges.

1. Dans nano, créez et ouvrez un fichier nommé psa-workload.yaml à l'aide de la commande suivante :

nano psa-workload.yaml

2. Une fois nano ouvert, collez la commande suivante dans le fichier psa-workload.yaml :

apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx securityContext: privileged: true

3. Appuyez sur Ctrl+O, puis sur Entrée pour enregistrer les modifications.

4. Appuyez sur Ctrl+X pour quitter l'éditeur de texte nano.

5. Appliquez le fichier manifeste à l'espace de noms "baseline-ns" :

kubectl apply -f psa-workload.yaml --namespace=baseline-ns

Le résultat ressemble à ce qui suit :

Warning: would violate PodSecurity "baseline:latest": privileged (container "nginx" must not set securityContext.privileged=true) pod/nginx created

La règle "baseline" autorise le pod à se déployer dans l'espace de noms.

6. Vérifiez que le pod a bien été déployé :

kubectl get pods --namespace=baseline-ns -l=app=nginx

7. Appliquez le fichier manifeste à l'espace de noms "restricted-ns" :

kubectl apply -f psa-workload.yaml --namespace=restricted-ns

Le résultat ressemble à ce qui suit :

Error from server (Forbidden): error when creating "workload.yaml": pods "nginx" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

Le pod ne se déploie pas dans l'espace de noms. Une entrée d'audit est ajoutée au journal.

Cliquez sur Vérifier ma progression pour valider l'objectif. Appliquer le fichier manifeste à l'espace de noms "restricted-ns"

Consulter les violations des règles dans les journaux d'audit

Les violations des règles dans les modes audit et forcé sont consignées dans les journaux d'audit de votre cluster. Vous pouvez les consulter à l'aide de l'explorateur de journaux de la console Google Cloud.

1. Dans la barre de titre de la console Google Cloud, saisissez Explorateur de journaux dans le champ Rechercher, puis cliquez sur Explorateur de journaux dans les résultats de recherche.

2. Dans le champ Requête, saisissez ce qui suit :

resource.type="k8s_cluster" protoPayload.response.reason="Forbidden" protoPayload.resourceName="core/v1/namespaces/restricted-ns/pods/nginx"

3. Cliquez sur Exécuter la requête.

4. Dans la section des résultats de la requête, développez l'entrée de journal "Forbidden". Le détail se présente comme suit :

{ ... protoPayload: { @type: "type.googleapis.com/google.cloud.audit.AuditLog" authenticationInfo: {1} authorizationInfo: [1] methodName: "io.k8s.core.v1.pods.create" request: {6} requestMetadata: {2} resourceName: "core/v1/namespaces/restricted-ns/pods/nginx" response: { @type: "core.k8s.io/v1.Status" apiVersion: "v1" code: 403 details: {2} kind: "Status" message: "pods "nginx" is forbidden: violates PodSecurity "restricted:latest": privileged (container "nginx" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")" metadata: {0} reason: "Forbidden" status: "Failure" } serviceName: "k8s.io" status: {2} } receiveTimestamp: "2022-12-01T19:19:25.353235326Z" resource: {2} timestamp: "2022-12-01T19:19:21.469360Z" }

(Facultatif) Tâche 3 : Effectuer une rotation des adresses IP et des identifiants

Effectuez la rotation des adresses IP et des identifiants sur votre cluster. Il s'agit d'une pratique de sécurité à exécuter régulièrement pour réduire la durée de vie des identifiants. Bien qu'il existe des commandes distinctes pour assurer la rotation des adresses IP et celle des identifiants, la rotation des identifiants permet aussi d'exécuter la rotation des adresses IP.

1. Dans Cloud Shell, exécutez la commande suivante :

gcloud container clusters update $my_cluster --zone $my_zone --start-credential-rotation

2. Saisissez Y pour continuer.
3. Ne fermez pas la page Cloud Shell avant la fin de l'opération.

Une fois la commande terminée dans Cloud Shell, le cluster lance le processus de mise à jour de chaque nœud. Ce processus peut prendre jusqu'à 15 minutes pour votre cluster. Notez qu'il actualise aussi automatiquement l'entrée kubeconfig pour l'utilisateur actuel.

4. Le maître de cluster sert maintenant temporairement la nouvelle adresse IP en plus de l'adresse d'origine.

Remarque : Avant de terminer le processus de rotation et pour éviter toute perte d'accès, vous devez mettre à jour le fichier kubeconfig sur l'ensemble des systèmes accédant au maître via kubectl ou une API.

5. Pour terminer les tâches de rotation des identifiants et des adresses IP, exécutez la commande suivante :

gcloud container clusters update $my_cluster --zone $my_zone --complete-credential-rotation

Cette opération finalise les processus de rotation et supprime l'adresse IP d'origine du cluster.

Remarque : Si la rotation des identifiants échoue et renvoie un message d'erreur, exécutez la commande ci-dessous. gcloud container clusters upgrade $my_cluster --node-pool=default-pool --zone $my_zone

6. Saisissez Y pour continuer.

7. Un fois le cluster mis à niveau, exécutez de nouveau la commande suivante :

gcloud container clusters update $my_cluster --zone $my_zone --complete-credential-rotation

Terminer l'atelier

Une fois l'atelier terminé, cliquez sur Terminer l'atelier. Google Cloud Skills Boost supprime les ressources que vous avez utilisées, puis efface le compte.

Si vous le souhaitez, vous pouvez noter l'atelier. Sélectionnez un nombre d'étoiles, saisissez un commentaire, puis cliquez sur Envoyer.

Le nombre d'étoiles correspond à votre degré de satisfaction :

• 1 étoile = très insatisfait(e)
• 2 étoiles = insatisfait(e)
• 3 étoiles = ni insatisfait(e), ni satisfait(e)
• 4 étoiles = satisfait(e)
• 5 étoiles = très satisfait(e)

Si vous ne souhaitez pas donner votre avis, vous pouvez fermer la boîte de dialogue.

Pour soumettre des commentaires, suggestions ou corrections, veuillez accéder à l'onglet Assistance.