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.

*The example code for this lab is provided as-is without warranty or guarantee*

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 ne permet plus ces actions.

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 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 gratuits.

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

Remarque : Pour afficher un menu contenant la liste des produits et services Google Cloud, cliquez 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.

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 us-central1-a. Si vous préférez, vous pouvez sélectionner une autre zone :

export MY_ZONE=us-central1-a

2. Exécutez la commande suivante pour démarrer un cluster Kubernetes géré par Kubernetes Engine, nommez-le simplecluster et configurez-le pour qu'il exécute deux nœuds :

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

La création d'un cluster prend plusieurs minutes, le temps que Kubernetes Engine provisionne les machines virtuelles. Dans cet atelier, vous pouvez ignorer en toute sécurité les avertissements relatifs aux 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 GCP. Dans le menu de navigation, cliquez sur Compute Engine > VM Instances (Instances de VM).

Votre cluster Kubernetes est maintenant prêt.

Cliquez sur Vérifier ma progression pour vérifier l'objectif.

Créer un cluster GKE simple

Exécuter un pod SDK Google Cloud

1. Lancez une instance unique du conteneur SDK Google Cloud depuis votre invite Cloud Shell :

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

Cette opération prend quelques minutes.

2. Vous avez maintenant une interface système bash dans le conteneur du pod :

root@gcloud:/#

Le démarrage du conteneur et l'affichage de l'invite de commande peuvent prendre quelques secondes. Si l'invite de commande ne s'affiche pas, essayez d'appuyer sur la touche Entrée.

Découvrir le point de terminaison de Legacy Compute Metadata

Exécutez à nouveau la commande, mais en utilisant cette fois le point de terminaison v1 de Compute Metadata :

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 <code>/computeMetadata/v1/instance/name</code> from this server. Missing Metadata-Flavor:Google header.
...snip...

Un message d'erreur indique qu'un en-tête HTTP personnalisé est nécessaire. Ajoutez l'en-tête personnalisé lors de l'exécution suivante et récupérez le nom de l'instance GCE 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

Lorsqu'un en-tête HTTP personnalisé n'est pas nécessaire pour accéder au point de terminaison des métadonnées de l'instance GCE, une faille présente dans une application peut permettre à un pirate informatique de détourner le code pour récupérer le contenu d'une URL Web qu'il aura saisie. Il s'agit d'une méthode simple d'énumération et d'exfiltration d'identifiants. En rendant nécessaire un en-tête HTTP personnalisé, le pirate informatique doit, une fois qu'il a exploité la faille de l'application qui lui permet de contrôler l'URL, ajouter des en-têtes personnalisés afin de réussir son attaque.

Conservez cette interface système à l'intérieur du pod qui sera utilisé à l'étape suivante. Si vous quittez accidentellement l'interface système 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 la même interface système du pod, exécutez la commande suivante pour répertorier les attributs associés aux instances GCE 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/

2. 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.

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

Considérons les situations suivantes :

1. Une faille dans une application de pod qui ouvre la voie à des attaques SSRF
2. Une faille dans une application ou dans une bibliothèque qui permet des attaques par RCE dans un pod
3. 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 élever les privilèges à 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 GCP ayant une API Compute activée disposent d'un compte de service par défaut au format NNNNNNNNNN-compute@developer.gserviceaccount.com dans le projet, et du rôle Editor qui y est rattaché. 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 répertorier les champs d'application OAuth associés au compte de service rattaché à l'instance GCE 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 spécifie les applications auxquelles ce nœud peut accéder. La liste ci-dessus définit les niveaux d'accès minimaux requis pour la plupart des clusters GKE, mais certains cas d'utilisation nécessitent des champs d'application supérieurs.

Si https://www.googleapis.com/auth/cloud-platform est inclus dans le champ d'application d'authentification à la création du cluster, n'importe quelle API GCP 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. Si vous utilisez le compte de service par défaut et que le rôle Editor par défaut de l'IAM n'a pas été modifié, cela signifie que tout pod sur ce pool de nœuds a des autorisations Editor pour le projet GCP dans lequel le cluster GKE est déployé. Étant donné que le rôle IAM Editor dispose d'un large éventail d'autorisations de lecture/écriture pour interagir avec les ressources du projet telles que les instances Compute, les buckets GCS, les registres GCR et autres, ce n'est pas souhaitable.

2. Pour quitter le pod, saisissez :

exit

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 le démontrer, 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 vérifier l'objectif.

Déployer un pod qui monte le système de fichiers hôte

Découvrir et compromettre l'hôte sous-jacent

Exécutez la commande suivante pour obtenir une interface système à l'intérieur du pod que vous venez de créer :

kubectl exec -it hostpath -- bash

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

chroot /rootfs /bin/bash

Grâce à ces commandes simples, le pod devient une interface système root sur 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.

Pour quitter l'interface système du pod, exécutez exit deux fois (une première fois pour quitter l'environnement chroot et une autre fois pour quitter l'interface système du pod) :

exit

exit

Vous pouvez maintenant supprimer le pod hostpath :

kubectl delete pod hostpath

Comprendre les options disponibles

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

• Désactiver l'ancien point de terminaison de l'API de métadonnées GCE : en spécifiant 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 sera installé sur chaque nœud, ce qui permettra de transférer toutes les requêtes à l'API de métadonnées et d'empêcher l'accès aux points de terminaison sensibles.

• Activer et configurer PodSecurityPolicy : en configurant cette option sur un cluster GKE, vous ajoutez le contrôleur d'admission PodSecurityPolicy, ce qui permet de restreindre l'utilisation de paramètres non sécurisés lors de la création du pod. Dans cette démonstration, nous allons empêcher les conteneurs de s'exécuter en tant qu'utilisateur racine et d'installer le système de fichiers hôte sous-jacent.

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ériques, les protections ne seront pas activées. Par contre, elles seront activées pour les pods programmés sur l'autre pool de nœuds.

Remarque : Dans la version 1.12 de GKE et les versions plus récentes, le paramètre --metadata=disable-legacy-endpoints=true sera automatiquement activé. Pour plus de clarté, la commande suivante décrit l'opération en détail.

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 vérifier l'objectif.

Déployer un deuxième pool de nœuds

Exécuter un pod SDK Google Cloud

1. Dans Cloud Shell, lancez une instance unique du conteneur SDK Google Cloud, 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

2. Vous avez maintenant une interface système bash à l'intérieur du conteneur du pod, qui s'exécute sur le pool de nœuds nommé second-pool. La page suivante doit normalement s'afficher :

nobody@gcloud:/$

Le démarrage du conteneur et l'affichage de l'invite de commande peuvent prendre quelques secondes.

Si l'invite de commande ne s'affiche pas, essayez d'appuyer sur la touche 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 pour 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 réussiront 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

Quittez le pod :

exit

Vous êtes maintenant être de retour dans Cloud Shell.

Déployer des objets PodSecurityPolicy

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. Déployez ensuite une règle PodSecurityPolicy plus restrictive sur tous les utilisateurs authentifiés de l'espace de noms par défaut :

cat <<EOF | kubectl apply -f -
---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restrictive-psp
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default'
    apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
    seccomp.security.alpha.kubernetes.io/defaultProfileName:  'docker/default'
    apparmor.security.beta.kubernetes.io/defaultProfileName:  'runtime/default'
spec:
  privileged: false
  # Required to prevent escalations to root.
  allowPrivilegeEscalation: false
  # This is redundant with non-root + disallow privilege escalation,
  # but we can provide it for defense in depth.
  requiredDropCapabilities:
    - ALL
  # Allow core volume types.
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    # Assume that persistentVolumes set up by the cluster admin are safe to use.
    - 'persistentVolumeClaim'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    # Require the container to run without root privileges.
    rule: 'MustRunAsNonRoot'
  seLinux:
    # This policy assumes the nodes are using AppArmor rather than SELinux.
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535
EOF

(Résultat)

podsecuritypolicy.extensions/restrictive-psp created

3. Ensuite, ajoutez le ClusterRole, l'élément-clé pour "utiliser" cette PodSecurityPolicy.

cat <<EOF | kubectl apply -f -
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: restrictive-psp
rules:
- apiGroups:
  - extensions
  resources:
  - podsecuritypolicies
  resourceNames:
  - restrictive-psp
  verbs:
  - use
EOF

(Résultat)

clusterrole.rbac.authorization.k8s.io/restrictive-psp created

4. Enfin, créez un "RoleBinding" dans l'espace de noms par défaut pour permettre à un utilisateur authentifié d'utiliser la "PodSecurityPolicy".

cat <<EOF | kubectl apply -f -
---
# All service accounts in kube-system
# can 'use' the 'permissive-psp' PSP
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: restrictive-psp
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: restrictive-psp
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
EOF

(Résultat)

rolebinding.rbac.authorization.k8s.io/restrictive-psp created

Remarque : En situation réelle, n'oubliez pas de remplacer l'utilisateur system:authenticated dans le RoleBinding par l'utilisateur ou les comptes de service spécifiques à qui vous souhaitez pouvoir donner la possibilité de créer des pods dans l'espace de noms par défaut.

Cliquez sur Vérifier ma progression pour vérifier l'objectif.

Déployer des objets PodSecurityPolicy

Activer la règle PodSecurity

Ensuite, activez le contrôleur d'admission PodSecurityPolicy :

gcloud beta container clusters update simplecluster --zone $MY_ZONE --enable-pod-security-policy

Cette opération prend quelques minutes.

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 du 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 credentials.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 PSP :

Error from server (Forbidden): error when creating "STDIN": pods "hostpath" is forbidden: unable to validate against any pod security policy: [spec.volumes[0]: Invalid value: "hostPath": hostPath volumes are not allowed to be used]

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:
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: hostpath
    image: google/cloud-sdk:latest
    command: ["/bin/bash"]
    args: ["-c", "tail -f /dev/null"]
EOF

(Résultat)

pod/hostpath created

9. Pour afficher l'annotation ajoutée au pod qui indique quelle règle PodSecurityPolicy a autorisé la création, exécutez la commande suivante :

kubectl get pod hostpath -o=jsonpath="{ .metadata.annotations.kubernetes\.io/psp }"

(Résultat ajouté à la ligne de commande Cloud Shell)

restrictive-psp

Cliquez sur Vérifier ma progression pour vérifier l'objectif.

Déployer un pod bloqué qui monte 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 ces actions malveillantes.

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 Security : autorisation binaire, ou consultez ces suggestions :

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

• Utiliser le contrôle des accès basé sur les rôles dans Kubernetes Engine

É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 en savoir plus, consultez la page https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster.

PodSecurityPolicy : https://cloud.google.com/kubernetes-engine/docs/how-to/pod-security-policies et https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#restrict_pod_permissions

Comptes de service des nœuds : https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#use_least_privilege_sa

Protéger les métadonnées des nœuds : https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#protect_node_metadata

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 : 11 juin 2021

Dernier test de l'atelier : 11 juin 2021

Copyright 2024 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.