GSP479

Présentation

L'un des principaux problèmes de sécurité concernant l'exécution de clusters Kubernetes est de savoir quelles images de conteneurs sont en cours d'exécution à l'intérieur de chaque pod, et d'être capable d'en expliquer l'origine. Établir "l'origine du conteneur" signifie être capable de tracer la source d'un conteneur à un point d'origine de confiance et de s'assurer que votre organisation suit les processus souhaités lors de la création de l'artefact (conteneur).

Voici quelques-uns des problèmes principaux :

• Origine sûre : Comment s'assurer que toutes les images du conteneur en cours d'exécution dans le cluster proviennent d'une source approuvée ?
• Cohérence et validation : Comment s'assurer que toutes les étapes de validation souhaitées ont été effectuées pour chaque build de conteneur et chaque déploiement ?
• Intégrité : Comment s'assurer qu'une fois leur origine prouvée, les conteneurs n'ont pas été modifiés avant l'exécution ?

Du point de vue de la sécurité, il est risqué de ne pas prendre de mesures concernant l'origine des images :

• Sans mesures d'application, un individu malveillant ayant compromis un conteneur pourrait réussir à obtenir des privilèges de clusters suffisants pour lancer d'autres conteneurs depuis une source inconnue.
• Un utilisateur autorisé à créer des pods pourrait, de façon accidentelle ou malveillante, exécuter un conteneur indésirable directement à l'intérieur d'un cluster.
• Un utilisateur autorisé pourrait, de façon accidentelle ou malveillante, écraser un tag d'image Docker avec un conteneur fonctionnel auquel on aurait ajouté silencieusement un code indésirable, et que Kubernetes extrairait et déploierait automatiquement dans le cadre d'un déploiement.

Pour aider les opérateurs de systèmes à résoudre ces problèmes, Google Cloud offre une fonctionnalité appelée autorisation binaire. L'autorisation binaire est un service géré de Google Cloud qui fonctionne étroitement avec GKE pour mettre en place des contrôles de sécurité lors du déploiement, afin que seules les images de conteneurs de confiance soient déployées. Avec l'autorisation binaire, vous pouvez ajouter des registres de conteneurs à la liste d'autorisation, exiger que les images soient signées par des autorités de confiance et appliquer ces stratégies de façon centralisée. Grâce à cette stratégie, vous pouvez obtenir un contrôle plus étroit sur votre environnement de conteneurs en vous assurant que seules les images approuvées ou vérifiées sont intégrées dans le processus de compilation et de déploiement.

Dans cet atelier, vous allez déployer un cluster Kubernetes Engine avec la fonctionnalité d'autorisation binaire activée, et apprendre à ajouter des registres de conteneurs approuvés à la liste d'autorisation. Il vous guidera également dans la création et l'exécution d'un conteneur signé.

Cet atelier a été conçu par les ingénieurs de GKE Helmsman pour vous aider à mieux comprendre l'autorisation binaire GKE. Nous invitons chacun à enrichir nos ressources !

Architecture

L'autorisation binaire et l'API Container Analysis sont basés sur les projets en Open Source Grafeas et Kritis.

• Grafeas définit les spécifications d'une API dans le but de gérer les métadonnées des ressources de logiciel, telles que les images de conteneurs, les images de machines virtuelles (VM), les fichiers JAR et les scripts. Vous pouvez utiliser Grafeas pour définir et agréger des renseignements concernant les composants de votre projet.
• Kritis définit une API pour s'assurer qu'un déploiement n'est possible que si l'artefact (image de conteneur) est conforme à la stratégie centrale, et en option, si l'artefact possède les attestations nécessaires.

Dans un pipeline de déploiement de conteneur simplifié comme celui-ci :

Le conteneur passe par au moins 4 étapes :

1. Le code source de création du conteneur est stocké dans un dépôt source.
2. Lorsque vous procédez au commit d'une modification dans le dépôt source, le conteneur est compilé et testé.
3. Si les étapes de compilation et de test sont effectuées, l'artefact de l'image de conteneur est alors positionné dans un registre de conteneurs central, prêt pour le déploiement.
4. Lorsqu'un déploiement de cette version de conteneur est soumis aux API Kubernetes, l'environnement d'exécution du conteneur extrait cette image de conteneur du registre de conteneurs et l'exécute en tant que pod.

Dans un pipeline de compilation de conteneurs, il existe des possibilités d'injecter des traitements complémentaires pour signifier ou "attester" que chaque étape a été effectuée avec succès. Il peut s'agir d'effectuer des tests unitaires, des analyses de contrôle des sources, des vérifications d'attribution de licence, des analyses de failles, etc. Chaque étape peut recevoir le pouvoir, ou "autorité d'attestation", de signer le bon achèvement de l'étape. Une "autorité d'attestation" est un humain ou un système disposant de la bonne clé PGP et de la capacité d'enregistrer cette "attestation" auprès de l'API Container Analysis.

En utilisant des clés PGP distinctes pour chaque étape, chaque étape d'attestation pourrait être effectuée par différents humains, systèmes, ou étapes de compilation dans le pipeline (a). Chaque clé PGP est associée à une "note d'attestation" qui est stockée dans l'API Container Analysis. Quand une étape de compilation "signe" une image, un extrait des métadonnées JSON de cette image est signé par PGP et envoyé à l'API en tant qu'"occurrence de note".

(b). Une fois l'image du conteneur compilée et les attestations nécessaires stockées de manière centralisée, elles sont disponibles à la requête dans le cadre d'un processus de décision stratégique. Dans ce cas, lorsqu'un contrôleur d'admission Kubernetes reçoit une requête API create de création ou update de mise à jour d'un pod :

1. Le contrôleur d'admission envoie un webhook à l'API d'autorisation binaire pour une décision stratégique.
2. La stratégie d'autorisation binaire est alors consultée.
3. Si nécessaire, l'API Container Analysis est également interrogée pour les occurrences d'attestation nécessaires.
4. Si l'image du conteneur est conforme à la stratégie, elle est autorisée à s'exécuter.
5. Si l'image du conteneur n'est pas conforme, une erreur est présentée au client de l'API avec un message décrivant la raison pour laquelle elle n'a pas été autorisée.

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

Tâche 1 : Copier les ressources

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

gsutil -m cp -r gs://spls/gke-binary-auth/* .

2. Accédez au répertoire suivant pour obtenir cette démonstration :

cd gke-binary-auth-demo

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

Mettre à jour les autorisations d'accès aux fichiers

• Autorisez les ressources nécessaires pour réaliser cet atelier à lire, modifier et exécuter certains fichiers.

chmod +x create.sh chmod +x delete.sh chmod 777 validate.sh

Tâche 2 : Définir une version de cluster par défaut

• Remplacez la variable GKE_VERSION de create.sh par defaultClusterVersion:

sed -i 's/validMasterVersions\[0\]/defaultClusterVersion/g' ./create.sh Remarque : La version de cluster par défaut sera compatible avec d'autres dépendances de cet atelier.

Tâche 3 : Procédure de déploiement

Remarque : Les instructions ci-dessous s'appliquent aux déploiements effectués avec et sans Cloud Shell.

• Pour déployer le cluster, exécutez la commande suivante. Vous pouvez remplacer le texte my-cluster-1 par le nom du cluster que vous souhaitez créer.

./create.sh -c my-cluster-1

Une fois l'exécution terminée, le script create affiche le message suivant :

kubeconfig entry generated for my-cluster-1. NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS my-cluster-1 {{{project_0.default_zone | Zone}}} 1.14.8-gke.17 104.154.181.211 n1-standard-1 1.14.8-gke.17 2 RUNNING Fetching cluster endpoint and auth data. kubeconfig entry generated for my-cluster-1.

Le script va :

1. activer les API nécessaires dans votre projet, plus précisément, container, containerregistry, containeranalysis et binaryauthorization ;
2. créer un nouveau cluster Kubernetes Engine dans votre ZONE, VPC et réseau par défaut ;
3. récupérer vos identifiants de cluster pour activer l'utilisation de kubectl.

Vous pouvez ignorer les avertissements.

Tâche 4 : Validation

• Le script suivant confirmera le bon déploiement de la démonstration :

./validate.sh -c my-cluster-1

Si le script échoue, il affichera :

Validation Failed: the BinAuthZ policy was NOT available

Et/ou

Validation Failed: the Container Analysis API was NOT available

Si le script fonctionne, il affichera :

Validation Passed: the BinAuthZ policy was available Validation Passed: the Container Analysis API was available

Tester la tâche terminée

Cliquez sur Vérifier ma progression pour valider la tâche exécutée. Si vous avez réussi à créer un cluster Kubernetes avec une autorisation binaire, une note d'évaluation s'affichera.

Créer un cluster Kubernetes avec une autorisation binaire

Tâche 5 : Utiliser l'autorisation binaire

Gérer la stratégie d'autorisation binaire

Pour accéder à l'interface utilisateur de configuration de la stratégie d'autorisation binaire, effectuez les étapes suivantes :

1. Dans la console Google Cloud, accédez à Sécurité > Autorisation binaire.

2. Cliquez sur Modifier la stratégie.

Remarque : Suivez les étapes ci-dessous pour accéder à la configuration de la stratégie d'autorisation binaire via gcloud.

Exécutez gcloud beta container binauthz policy export > policy.yaml.

Apportez les modifications nécessaires à policy.yaml.

Exécutez gcloud beta container binauthz policy import policy.yaml.

La stratégie que vous modifiez est la stratégie par défaut. Elle s'applique à tous les clusters GKE du projet Google Cloud, sauf s'il existe une stratégie spécifique aux clusters.

Nous vous recommandons de créer des stratégies spécifiques pour chaque cluster et d'en vérifier le bon fonctionnement (en ajoutant les registres à la liste d'autorisation si nécessaire), puis de sélectionner "Refuser toutes les images" comme stratégie par défaut au niveau du projet. Chaque nouveau cluster dans ce projet aura ensuite besoin de sa propre stratégie spécifique aux clusters.

3. Après avoir cliqué sur Modifier la règle, vous verrez s'afficher ce qui suit. Cliquez sur la flèche vers le bas à côté de Règles d'exception personnalisées pour les afficher :

La stratégie par défaut est Allow all images (Autoriser toutes les images). Cela imite le comportement qui se produirait si l'autorisation binaire n'était pas activée dans le cluster.

Si la règle par défaut est modifiée et devient Disallow all images (Interdire toutes les images) ou Allow only images that have been approved by all of the following attestors (Autoriser uniquement les images qui ont été approuvées par tous les certificateurs suivants), les images qui ne correspondent pas aux chemins d'accès de l'image de registre exemptés ou qui n'ont pas les attestations nécessaires seront bloquées, respectivement.

Ensuite, apportez quelques modifications à la stratégie :

4. Définissez votre règle par défaut sur Disallow all images (Interdire toutes les images).

5. Dans "Paramètres supplémentaires pour les déploiements GKE et Anthos", cliquez sur Créer des règles spécifiques.

6. Dans le menu déroulant, sélectionnez Cluster GKE, puis cliquez sur Modifier.

7. Sous Règles spécifiques aux clusters GKE, cliquez sur Ajouter une règle spécifique.

8. Dans le champ Ajouter une règle spécifique aux clusters GKE, saisissez l'emplacement et le nom du cluster au format location.clustername, par exemple .my-cluster-1 qui correspond à la zone et au nom du cluster my-cluster-1.

9. Sélectionnez la règle par défaut Allow all images (Autoriser toutes les images) pour votre cluster.

10. Cliquez sur AJOUTER.

11. Cliquez sur Enregistrer la stratégie.

Tester la tâche terminée

Cliquez sur Vérifier ma progression pour valider la tâche exécutée. Si vous avez bien mis à jour la stratégie d'autorisation binaire pour ajouter la règle Disallow all images (Interdire toutes les images) au niveau du projet et autoriser toutes les images au niveau du cluster, vous recevrez une note d'évaluation.

Mettre à jour la stratégie d'autorisation binaire pour ajouter la règle Disallow all images (Interdire toutes les images) au niveau du projet et autoriser toutes les images au niveau du cluster

Tâche 6 : Créer une image GCR privée

1. Pour simuler une configuration dans un cas réel, créez une image de conteneur GCR privée dans votre projet.

2. Ensuite, extrayez le conteneur nginx du projet nginx et transférez-le dans votre propre dépôt GCR sans modification.

3. Dans Cloud Shell, extrayez le dernier conteneur nginx (latest nginx) :

docker pull nginx:latest

4. Authentifiez Docker dans le projet :

gcloud auth configure-docker

Lorsque l'invite Do you want to continue (Y/n)? (Voulez-vous continuer (OUI/non) ?) apparaît, appuyez sur Y.

5. Paramétrez la variable de l'interface PROJECT_ID :

PROJECT_ID="$(gcloud config get-value project)"

6. Attribuez-lui un tag et transférez-la dans le GCR du projet actuel :

docker tag nginx "gcr.io/${PROJECT_ID}/nginx:latest" docker push "gcr.io/${PROJECT_ID}/nginx:latest"

7. Répertoriez l'image nginx "privée" dans votre propre dépôt GCR :

gcloud container images list-tags "gcr.io/${PROJECT_ID}/nginx"

Tâche 7 : Refuser toutes les images

Pour vous assurer que le refus des images par la stratégie fonctionnera comme souhaité, vérifiez tout d'abord que la règle spécifique au cluster allow (autoriser) est en place et autorise tous les conteneurs à s'exécuter.

1. Pour ce faire, lancez un unique pod nginx :

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: "gcr.io/${PROJECT_ID}/nginx:latest" ports: - containerPort: 80 EOF

Un message indiquant pod/nginx created doit s'afficher.

2. Répertoriez les pods :

kubectl get pods

Résultat :

NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 1m

Si cela échoue, vérifiez à nouveau la région et le nom spécifiques à votre cluster et réessayez.

3. À présent, supprimez ce pod :

kubectl delete pod nginx

4. Ensuite, prouvez que la stratégie d'autorisation binaire peut bloquer les images indésirables en les empêchant de s'exécuter dans le cluster.

Sur la page d'autorisation binaire, cliquez sur Modifier la stratégie.

5. Cliquez sur les trois points verticaux à droite de votre règle spécifique aux clusters GKE, puis sur Modifier.

6. Ensuite, sélectionnez Interdire toutes les images et cliquez sur Envoyer.

Votre stratégie doit ressembler à ceci :

7. Enfin, cliquez sur Enregistrer la stratégie pour appliquer ces changements.

Remarque : Attendez au moins 30 secondes avant de continuer pour que les changements soient pris en compte.

Tester la tâche terminée

Cliquez sur Vérifier ma progression pour valider la tâche exécutée. Si vous avez réussi à faire passer la stratégie d'autorisation binaire à la règle Disallow all images (Interdire toutes les images) au niveau du cluster, une note d'évaluation s'affichera.

Mettre à jour la stratégie spécifique au cluster pour interdire toutes les images

8. À présent, exécutez la même commande que précédemment pour créer le pod statique nginx :

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: "gcr.io/${PROJECT_ID}/nginx:latest" ports: - containerPort: 80 EOF

Cette fois-ci cependant, vous recevez un message du serveur de l'API indiquant que la stratégie a empêché ce pod de s'exécuter correctement :

Error from server (VIOLATES_POLICY): error when creating "STDIN": admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/qwiklabs-gcp-00-ce851250686b/nginx:latest denied by Binary Authorization cluster admission rule for {{{project_0.default_zone | Zone}}}.my-cluster-1. Denied by always_deny admission rule

Pour déterminer à quel moment les images sont bloquées par la stratégie d'autorisation binaire, accédez aux journaux d'audit GKE dans Stackdriver et filtrez les messages d'erreurs liés à cette activité.

9. Dans la console Google Cloud, accédez au menu de navigation > Journalisation > Explorateur de journaux.
10. Dans la zone de texte du générateur de requêtes, saisissez :

resource.type="k8s_cluster" protoPayload.response.reason="VIOLATES_POLICY"

11. Cliquez sur Exécuter la requête.
12. Vous devez voir des erreurs correspondant au blocage de l'exécution du pod nginx.

Tester la tâche terminée

Cliquez sur Vérifier ma progression pour valider la tâche exécutée. Si vous avez réussi à vérifier la règle d'admission du cluster, vous verrez une note d'évaluation s'afficher.

Créer un pod Nginx pour vérifier que la règle d'admission du cluster est appliquée pour interdire toutes les images (refus de créer)

Tâche 8 : Refuser les images, sauf celles des registres de conteneurs ajoutés à la liste d'autorisation

1. Supposons que vous souhaitiez en réalité autoriser uniquement ce conteneur nginx à s'exécuter. Le moyen le plus rapide est d'ajouter à la liste d'autorisation le registre dont il provient.

2. Utilisez le résultat de la commande suivante en tant que chemin d'accès de votre image :

echo "gcr.io/${PROJECT_ID}/nginx*"

3. Copiez le chemin d'accès de l'image dans votre tampon.

4. Accédez au menu de navigation > Sécurité > Autorisation binaire.

5. Modifiez la stratégie d'autorisation binaire. Sous Règles d'exception personnalisées, affichez les chemins d'accès de l'image, puis cliquez sur Ajouter un format d'image.

6. Collez le chemin d'accès de l'image que vous avez copié précédemment et cliquez sur Terminé. L'image ci-dessous montre un exemple de chemin d'accès.

7. Cliquez sur Enregistrer la stratégie, puis exécutez la commande suivante :

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: "gcr.io/${PROJECT_ID}/nginx:latest" ports: - containerPort: 80 EOF

Vous devez maintenant pouvoir lancer ce pod et vérifier que l'ajout de registre à la liste d'autorisation fonctionne correctement.

8. Exécutez la commande suivante pour effectuer un nettoyage et une préparation aux étapes à venir :

kubectl delete pod nginx

Tester la tâche terminée

Cliquez sur Vérifier ma progression pour valider la tâche exécutée. Si vous avez réussi à mettre à jour la stratégie d'autorisation binaire pour ajouter le registre de conteneur à la liste d'autorisation, une note d'évaluation s'affichera.

Mettre à jour la stratégie d'autorisation binaire pour refuser les images, sauf celles des registres de conteneurs ajoutés à la liste d'autorisation (le registre de conteneurs de votre projet)

Tâche 9 : Appliquer des attestations

Ajouter des registres d'images de conteneurs à la liste d'autorisation constitue une excellente première étape pour empêcher les images de conteneurs indésirables d'être exécutées dans un cluster. Cependant, il existe d'autres mesures que vous pouvez prendre pour vous assurer que le conteneur est créé correctement.

Nous vous conseillons de vérifier de manière cryptographique qu'une image de conteneur donnée a été approuvée pour le déploiement. Ceci est effectué par une "autorité d'attestation" qui indique ou atteste le fait qu'une étape en particulier a été effectuée. Pour ce faire, l'autorité d'attestation utilise une clé PGP pour signer un extrait de métadonnées décrivant le hachage SHA256 d'une image de conteneur et l'envoie à un dépôt de métadonnées central : l'API Container Analysis.

Plus tard, lorsque le contrôleur d'admission confirmera si une image de conteneur est autorisée à s'exécuter en consultant une stratégie d'autorisation binaire qui nécessite la présence d'attestations sur une image, il vérifiera si l'API Container Analysis contient les extraits signés des métadonnées indiquant quelles étapes ont été effectuées. Grâce à ces renseignements, le contrôleur d'admission saura s'il doit autoriser ou refuser l'exécution de ce pod.

Ensuite, exécutez une attestation manuelle d'une image de conteneur. Vous jouerez le rôle d'une autorité d'attestation humaine et vous effectuerez toutes les étapes pour signer une image de conteneur, créer une stratégie exigeant la présence de cette attestation sur les images s'exécutant dans votre cluster, puis diffuser cette image dans un pod.

Configurer les variables nécessaires

1. Nom/adresse e-mail du certificateur :

ATTESTOR="manually-verified" # No spaces allowed ATTESTOR_NAME="Manual Attestor" ATTESTOR_EMAIL="$(gcloud config get-value core/account)" # This uses your current user/email

2. ID/description de note Container Analysis de votre autorité d'attestation :

NOTE_ID="Human-Attestor-Note" # No spaces NOTE_DESC="Human Attestation Note Demo"

3. Noms pour que les fichiers créent des charges utiles/requêtes :

NOTE_PAYLOAD_PATH="note_payload.json" IAM_REQUEST_JSON="iam_request.json"

Créer une note d'attestation

La première étape consiste à enregistrer l'autorité d'attestation en tant que note Container Analysis avec l'API Container Analysis. Pour ce faire, vous créerez une note d'ATTESTATION et l'enverrez à l'API.

1. Créez la charge utile de la note d'ATTESTATION :

cat > ${NOTE_PAYLOAD_PATH} << EOF { "name": "projects/${PROJECT_ID}/notes/${NOTE_ID}", "attestation_authority": { "hint": { "human_readable_name": "${NOTE_DESC}" } } } EOF

2. Envoyez la note d'ATTESTATION à l'API Container Analysis :

curl -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ --data-binary @${NOTE_PAYLOAD_PATH} \ "https://containeranalysis.googleapis.com/v1beta1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

Vous verrez que le résultat de la commande précédente affiche la note créée. La commande suivante permet aussi de l'afficher :

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://containeranalysis.googleapis.com/v1beta1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

Créer une clé de signature PGP

Pendant que votre autorité d'attestation utilise une clé PGP pour effectuer la signature cryptographique des métadonnées de l'image, créez une nouvelle clé PGP et exportez la clé PGP publique.

Remarque : Ces messages d'erreur concernent cette activité. La clé PGP n'est pas protégée par un mot de passe pour cet exercice. Dans un système de production, assurez-vous de sauvegarder correctement vos clés PGP privées.

1. Configurez une autre variable de shell :

PGP_PUB_KEY="generated-key.pgp"

2. Créez la clé PGP :

sudo apt-get install rng-tools sudo rngd -r /dev/urandom gpg --quick-generate-key --yes ${ATTESTOR_EMAIL}

3. Appuyez sur Entrée pour utiliser une phrase secrète vide et accuser réception des avertissements.

4. Extrayez la clé PGP publique :

gpg --armor --export "${ATTESTOR_EMAIL}" > ${PGP_PUB_KEY}

Enregistrer le certificateur dans l'API d'autorisation binaire

L'étape suivante consiste à créer le "certificateur" dans l'API d'autorisation binaire et à y ajouter la clé PGP publique.

1. Créez le certificateur dans l'API d'autorisation binaire :

gcloud --project="${PROJECT_ID}" \ beta container binauthz attestors create "${ATTESTOR}" \ --attestation-authority-note="${NOTE_ID}" \ --attestation-authority-note-project="${PROJECT_ID}"

2. Ajoutez la clé PGP au certificateur :

gcloud --project="${PROJECT_ID}" \ beta container binauthz attestors public-keys add \ --attestor="${ATTESTOR}" \ --pgp-public-key-file="${PGP_PUB_KEY}"

3. Répertoriez le certificateur nouvellement créé :

gcloud --project="${PROJECT_ID}" \ beta container binauthz attestors list

Le résultat doit ressembler à ce qui suit :

NAME: manually-verified NOTE: projects//notes/Human-Attestor-Note NUM_PUBLIC_KEYS: 1

Tâche 10 : "Signer" une image de conteneur

Les étapes précédentes ne doivent être effectuées qu'une fois. À partir de ce moment, cette étape est la seule qui doive être répétée pour chaque nouvelle image de conteneur.

L'image nginx sur nginx:latest est déjà créée et disponible pour utilisation. Effectuez-y les attestations manuelles comme s'il s'agissait de votre propre image créée par vos propres processus, et épargnez-vous l'effort de devoir la créer.

1. Configurez quelques variables de shell :

GENERATED_PAYLOAD="generated_payload.json" GENERATED_SIGNATURE="generated_signature.pgp"

2. Obtenez l'empreinte PGP :

PGP_FINGERPRINT="$(gpg --list-keys ${ATTESTOR_EMAIL} | head -2 | tail -1 | awk '{print $1}')"

3. Obtenez le condensé SHA256 de l'image de conteneur :

IMAGE_PATH="gcr.io/${PROJECT_ID}/nginx" IMAGE_DIGEST="$(gcloud container images list-tags --format='get(digest)' $IMAGE_PATH | head -1)"

4. Créez une charge utile de signature au format JSON :

gcloud beta container binauthz create-signature-payload \ --artifact-url="${IMAGE_PATH}@${IMAGE_DIGEST}" > ${GENERATED_PAYLOAD}

5. Affichez la charge utile de signature générée :

cat "${GENERATED_PAYLOAD}"

6. "Signez" la charge utile avec la clé PGP :

gpg --local-user "${ATTESTOR_EMAIL}" \ --armor \ --output ${GENERATED_SIGNATURE} \ --sign ${GENERATED_PAYLOAD}

7. Affichez la signature générée (message PGP) :

cat "${GENERATED_SIGNATURE}"

8. Créez l'attestation :

gcloud beta container binauthz attestations create \ --artifact-url="${IMAGE_PATH}@${IMAGE_DIGEST}" \ --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR}" \ --signature-file=${GENERATED_SIGNATURE} \ --public-key-id="${PGP_FINGERPRINT}"

9. Affichez l'attestation nouvellement créée :

gcloud beta container binauthz attestations list \ --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR}"

Tâche 11 : Diffuser une image avec la mesure d'attestation activée

La prochaine étape consiste à modifier la stratégie d'autorisation binaire pour s'assurer que l'attestation est présente sur toutes les images qui ne correspondent pas aux critères de la liste d'autorisation.

1. Pour changer la stratégie et exiger l'attestation, exécutez la commande suivante, puis copiez l'intégralité du chemin d'accès/du nom de l'autorité d'attestation :

echo "projects/${PROJECT_ID}/attestors/${ATTESTOR}" # Copy this output to your copy/paste buffer

2. Ensuite, modifiez la stratégie d'autorisation binaire pour Modifier la règle spécifique au cluster.

Cliquez sur les trois points à côté du nom de votre cluster, puis sur Modifier pour modifier les règles spécifiques à votre cluster.

3. Sélectionnez Exiger des attestations : autoriser uniquement les images qui ont été validées par les certificateurs suivants plutôt qu'Interdire toutes les images dans la fenêtre pop-up.

4. Cliquez ensuite sur Ajouter des certificateurs, puis sur Ajouter par ID de ressource de certificateur. Saisissez le contenu de votre tampon copier/coller au format projects/${PROJECT_ID}/attestors/${ATTESTOR}, puis cliquez sur Ajouter un certificateur, sur Envoyer et enfin sur Enregistrer la stratégie.

La stratégie par défaut devrait encore afficher Disallow all images (Interdire toutes les images), mais la règle spécifique au cluster devrait exiger une attestation.

5. Maintenant, obtenez le condensé SHA256 le plus récent de l'image signée des étapes précédentes :

IMAGE_PATH="gcr.io/${PROJECT_ID}/nginx" IMAGE_DIGEST="$(gcloud container images list-tags --format='get(digest)' $IMAGE_PATH | head -1)"

6. Après avoir attendu au moins 30 secondes depuis le moment de la mise à jour de la stratégie d'autorisation binaire, exécutez le pod et vérifiez si cela a fonctionné :

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: "${IMAGE_PATH}@${IMAGE_DIGEST}" ports: - containerPort: 80 EOF

Félicitations ! Vous avez maintenant certifié manuellement une image de conteneur et mis en place une stratégie pour cette image dans votre cluster GKE.

Tester la tâche terminée

Cliquez sur Vérifier ma progression pour valider la tâche exécutée. Si vous avez réussi à mettre à jour la stratégie d'autorisation binaire pour modifier la règle spécifique au cluster afin de n'autoriser que les images approuvées par les certificateurs, une note d'évaluation s'affichera.

Mettre à jour la stratégie d'AB pour modifier la règle spécifique au cluster afin de n'autoriser que les images ayant été approuvées par les certificateurs

Tâche 12 : Gérer les situations d'urgence

Du point de vue d'un utilisateur, la stratégie d'autorisation binaire peut bloquer de façon erronée une image ou provoquer un autre problème lié au bon fonctionnement du webhook du contrôleur d'admission.

Dans ce cas d'"urgence", il existe une fonctionnalité "bris de glace" qui utilise une annotation spécifique pour signaler au contrôleur d'admission d'exécuter le pod et d'ignorer l'application de la stratégie.

Remarque : Nous vous conseillons d'avertir une équipe de sécurité lorsque cela se produit, car des utilisateurs malveillants peuvent s'en servir s'ils ont la capacité de créer un pod.

Cependant, dans ce cas, vos procédures d'urgence peuvent être lancées quelques secondes après l'événement. Les journaux sont disponibles dans Stackdriver :

1. Pour exécuter un conteneur nginx non signé avec l'annotation "bris de glace", exécutez :

cat << EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: nginx-alpha annotations: alpha.image-policy.k8s.io/break-glass: "true" spec: containers: - name: nginx image: "nginx:latest" ports: - containerPort: 80 EOF

2. Dans la console Google Cloud, accédez au menu de navigation > Journalisation > Explorateur de journaux.

3. Dans la zone de texte Générateur de requêtes, saisissez la commande suivante, puis cliquez sur Exécuter la requête.

   resource.type="k8s_cluster" protoPayload.request.metadata.annotations."alpha.image-policy.k8s.io/break-glass"="true"

4. Les événements où le contrôleur d'admission a autorisé un pod en raison de la présence de l'annotation sont affichés. Depuis ce filtre, vous pouvez créer un Sink (récepteur) qui enverra des journaux correspondant à ce filtre à une destination externe.

Remarque : L'affichage des journaux prend au moins 5 à 10 minutes.

Tâche 13 : Suppression

Qwiklabs supprimera toutes les ressources que vous avez créées pour cet atelier, mais il est bon de savoir comment nettoyer votre propre environnement.

1. Le script suivant détruira le cluster Kubernetes Engine :

./delete.sh -c my-cluster-1

Si vous avez créé votre propre nom de cluster au début de cet atelier, utilisez-le. Dans cet exemple, nous avons utilisé le nom my-cluster-1.

Les dernières lignes du résultat seront :

Deleting cluster Remarque : La commande de suppression du cluster s'exécute de façon asynchrone et prendra un peu de temps à être supprimée. Vous pouvez suivre la progression dans la console Cloud ou via la commande gcloud container clusters list. Attendez que le cluster soit supprimé.

Tester la tâche terminée

Cliquez sur Vérifier ma progression pour valider la tâche exécutée. Si vous avez réussi à supprimer votre cluster, une note d'évaluation s'affichera.

Suppression (supprimer le cluster)

Les commandes suivantes supprimeront les ressources restantes.

2. Supprimez l'image de conteneur qui a été transférée à GCR :

gcloud container images delete "${IMAGE_PATH}@${IMAGE_DIGEST}" --force-delete-tags

3. Si l'invite Do you want to continue (Y/n)? (Voulez-vous continuer (OUI/non) ?) s'affiche, saisissez Y.

4. Supprimez le certificateur :

gcloud --project="${PROJECT_ID}" \ beta container binauthz attestors delete "${ATTESTOR}"

5. Supprimez la note Container Analysis :

curl -X DELETE \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://containeranalysis.googleapis.com/v1beta1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

Dépannage dans votre environnement

1. Si vous mettez à jour la stratégie d'autorisation binaire et essayez très rapidement de lancer un nouveau pod ou conteneur, la stratégie n'aura peut-être pas le temps de prendre effet. Vous devrez peut-être attendre 30 secondes ou plus pour que le changement de stratégie devienne actif. Pour réessayer, supprimez votre pod en utilisant kubectl delete <nomdupod> et envoyez à nouveau la commande de création de pod.
2. Exécutez la commande gcloud container clusters list pour vérifier l'état du cluster.
3. Si vous activez des fonctionnalités complémentaires comme --enable-network-policy, --accelerator, --enable-tpu ou --enable-metadata-concealment, vous devrez peut-être ajouter des registres supplémentaires à la liste d'autorisation de votre stratégie d'autorisation binaire pour que ces pods puissent s'exécuter. Utilisez la commande kubectl describe pod <podname> pour trouver le chemin d'accès du registre depuis la spécification d'image et l'ajouter à la liste d'autorisation au format gcr.io/example-registry/*. Ensuite, enregistrez la stratégie.
4. Si vous obtenez des erreurs concernant les quotas, augmentez vos quotas dans le projet. Consultez la documentation sur les quotas de ressources pour en savoir plus.

Supports concernés

1. Quotas Google Cloud
2. Inscription à Google Cloud
3. Google Cloud Shell
4. Autorisation binaire dans GKE
5. Notes Container Analysis
6. Contrôleur d'admission Kubernetes
7. Étapes de lancement

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 un parcours de formation. Si vous terminez cette quête, vous obtenez un badge 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. Découvrez toutes les quêtes disponibles dans le catalogue Google Cloud Skills Boost.

Atelier suivant

Continuez votre quête en suivant l'atelier Utiliser une stratégie de réseau dans Kubernetes Engine, ou consultez les suggestions suivantes :

• Utiliser le contrôle des accès basé sur les rôles dans Kubernetes Engine
• Renforcer la sécurité des configurations par défaut des clusters GKE

Dernière modification du manuel : 11 octobre 2023

Dernier test de l'atelier : 11 octobre 2023

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.