GSP480

Présentation

Dans cet atelier, vous allez découvrir comment améliorer la sécurité de Kubernetes Engine en appliquant des restrictions ultraprécises aux communications réseau.

Le principe du moindre privilège est largement reconnu comme étant un élément de conception important pour améliorer la protection de systèmes critiques contre les défaillances et les comportements malveillants. Selon ce principe, chaque composant doit pouvoir accéder uniquement aux informations et aux ressources qui sont nécessaires à son objectif légitime. Ce document explique comment le principe du moindre privilège peut être mis en œuvre dans la couche réseau de Kubernetes Engine.

Les connexions réseau peuvent être limitées à deux niveaux de votre infrastructure Kubernetes Engine. Le premier mécanisme, moins précis, consiste à appliquer des règles de pare-feu aux niveaux du réseau, du sous-réseau et de l'hôte. Ces règles sont appliquées en dehors de Kubernetes Engine, au niveau du VPC.

Bien que les règles de pare-feu soient une mesure de sécurité très efficace, Kubernetes vous permet de définir des règles de réseau encore plus précises qui renforcent la sécurité. Les règles de réseau permettent de limiter la communication au sein du cluster. Les règles de réseau ne s'appliquent pas aux pods associés à l'espace de noms réseau de l'hôte.

Dans cet atelier, vous allez provisionner un cluster privé Kubernetes Engine, puis un hôte bastion qui vous permettra d'y accéder. Un hôte bastion fournit un seul hôte qui a accès au cluster et qui, combiné à un réseau Kubernetes privé, garantit que le cluster ne s'expose pas à des comportements malveillants provenant d'Internet. Les hôtes bastion sont particulièrement utiles lorsque vous n'avez pas d'accès VPN au réseau cloud.

Au sein du cluster, un serveur HTTP simple et deux pods clients seront provisionnés. Vous allez apprendre à utiliser une règle de réseau et à ajouter des libellés pour n'autoriser les connexions qu'à partir d'un des pods clients.

Cet atelier a été conçu par les ingénieurs de GKE Helmsman pour vous aider à mieux comprendre l'autorisation binaire GKE. Pour regarder cette démonstration, exécutez les commandes gsutil cp -r gs://spls/gke-binary-auth/* . et cd gke-binary-auth-demo dans Cloud Shell. Nous vous invitons tous à enrichir nos ressources !

Architecture

Vous allez définir un cluster privé Kubernetes en mode standard qui utilise Dataplane V2. Les règles de réseau de Dataplane V2 sont activées par défaut.

Le cluster étant privé, ni l'API ni les nœuds de calcul ne seront accessibles depuis Internet. Vous allez plutôt définir un hôte bastion et utiliser une règle de pare-feu pour autoriser l'accès au cluster. L'adresse IP de l'hôte bastion est définie comme un réseau autorisé pour le cluster, qui lui donne accès à l'API.

Provisionnez trois charges de travail dans le cluster :

1. hello-server : il s'agit d'un serveur HTTP simple ayant un point de terminaison accessible en interne.
2. hello-client-allowed : il s'agit d'un seul pod qui tente à plusieurs reprises d'accéder à hello-server. Le pod est associé à un libellé de sorte que la règle de réseau l'autorise à se connecter à hello-server.
3. hello-client-blocked : il fonctionne avec le même code que hello-client-allowed, mais le pod est associé à un libellé de sorte que la règle de réseau ne l'autorise pas à se connecter à hello-server.

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.

Cloner la démonstration

1. Copiez les ressources nécessaires pour réaliser l'exercice de cet atelier depuis un bucket Cloud Storage :

gsutil cp -r gs://spls/gsp480/gke-network-policy-demo .

2. Accédez au répertoire de la démonstration :

cd gke-network-policy-demo

3. Rendez les fichiers de démonstration exécutables :

chmod -R 755 *

Tâche 1 : Mettre en place l'atelier

Tout d'abord, définissez la région et la zone Google Cloud.

1. Définissez la région Google Cloud :

gcloud config set compute/region "{{{project_0.default_region|placeholder}}}"

2. Définissez la zone Google Cloud :

gcloud config set compute/zone "{{{project_0.default_zone|placeholder}}}"

Dans cet atelier, vous allez utiliser les API de service Google Cloud suivantes, qui ont été activées pour vous :

• compute.googleapis.com
• container.googleapis.com
• cloudbuild.googleapis.com

De plus, la configuration Terraform nécessite trois paramètres pour déterminer l'endroit où le cluster Kubernetes Engine doit être créé :

• project ID
• region
• Zone

Par souci de simplicité, ces paramètres sont spécifiés dans un fichier nommé terraform.tfvars, dans le répertoire terraform.

3. Pour vous assurer que les API appropriées sont activées et pour générer le fichier terraform/terraform.tfvars selon vos paramètres gcloud par défaut, exécutez cette commande :

make setup-project

4. Lorsque vous y êtes invité, saisissez y pour confirmer.

Les API de service nécessaires vont alors être activées et le fichier terraform/terraform.tfvars va être généré avec les clés suivantes.

5. Vérifiez que les valeurs correspondent à celle du résultat de la commande gcloud config list en exécutant la commande suivante :

cat terraform/terraform.tfvars

Provisionner le cluster Kubernetes Engine

1. Ensuite, appliquez la configuration de Terraform dans la racine du projet :

make tf-apply

2. Lorsque vous y êtes invité, consultez le plan généré et saisissez yes pour déployer l'environnement.

Le déploiement prend quelques minutes.

Tâche 2 : Validation

Terraform renvoie un message lorsque le cluster est créé.

...snip... google_container_cluster.primary: Still creating... (3m0s elapsed) google_container_cluster.primary: Still creating... (3m10s elapsed) google_container_cluster.primary: Still creating... (3m20s elapsed) google_container_cluster.primary: Still creating... (3m30s elapsed) google_container_cluster.primary: Creation complete after 3m34s (ID: gke-demo-cluster) Apply complete! Resources: 5 added, 0 changed, 0 destroyed.

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 à déployer l'infrastructure nécessaire avec Terraform, vous verrez une note s'afficher.

Configurer l'infrastructure nécessaire avec Terraform (Mettre en place l'atelier)

1. Connectez-vous maintenant en SSH à l'hôte bastion pour les étapes restantes :

gcloud compute ssh gke-demo-bastion

Les versions existantes de kubectl et les clients Kubernetes personnalisés contiennent du code spécifique au fournisseur pour gérer l'authentification entre le client et Google Kubernetes Engine. À partir de la version 1.26, ce code ne sera plus inclus dans kubectl Open Source. Les utilisateurs de GKE devront télécharger et utiliser un plug-in d'authentification distinct pour générer des jetons spécifiques à GKE. Ce nouveau binaire, gke-gcloud-auth-plugin, exploite le mécanisme des plug-ins d'identification Kubernetes client-go pour étendre l'authentification de kubectl à GKE. Pour en savoir plus, vous pouvez consulter cette documentation.

Pour que kubectl utilise le nouveau plug-in binaire pour l'authentification plutôt que le code par défaut spécifique au fournisseur, procédez comme décrit ci-dessous.

2. Une fois connecté, exécutez la commande suivante pour installer gke-gcloud-auth-plugin sur la VM :

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin

3. Définissez export USE_GKE_GCLOUD_AUTH_PLUGIN=True dans ~/.bashrc :

echo "export USE_GKE_GCLOUD_AUTH_PLUGIN=True" >> ~/.bashrc

4. Exécutez la commande suivante :

source ~/.bashrc

5. Exécutez la commande suivante pour forcer la mise à jour de la configuration de ce cluster vers la configuration du plug-in d'identification client-go.

gcloud container clusters get-credentials gke-demo-cluster --zone {{{project_0.default_zone|placeholder}}}

Si l'opération réussit, le message suivant doit s'afficher :

kubeconfig entry generated for gke-demo-cluster.

Vous pouvez désormais utiliser les commandes kubectl standards sur l'hôte bastion pour le cluster que vous venez de créer.

Tâche 3 : Installer hello-server

L'application de test comprend un serveur HTTP simple déployé en tant que service hello-server, et deux clients, dont l'un comporte le libellé app=hello et l'autre, le libellé app=not-hello.

Ces trois services peuvent être déployés en appliquant les fichiers manifestes d'application hello-app.

1. Sur l'hôte bastion, exécutez la commande suivante :

kubectl apply -f ./manifests/hello-app/

Résultat :

deployment.apps/hello-client-allowed created deployment.apps/hello-client-blocked created service/hello-server created deployment.apps/hello-server created

2. Vérifiez que les trois pods ont bien été déployés :

kubectl get pods

Vous remarquerez qu'un pod est en cours d'exécution pour chacun des déploiements hello-client-allowed, hello-client-blocked et hello-server.

NAME READY STATUS RESTARTS AGE hello-client-allowed-7d95fcd5d9-t8fsk | 1/1 Running 0 14m hello-client-blocked-6497db465d-ckbn8 | 1/1 Running 0 14m hello-server-7df58f7fb5-nvcvd | 1/1 Running 0 14m

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 à déployer un service hello-server HTTP simple, vous verrez une note s'afficher.

Installer hello-server

Tâche 4 : Confirmer l'accès par défaut au service hello-server

1. Commencez par afficher les dernières lignes du client "autorisé" :

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=hello)

Appuyez sur Ctrl+C pour quitter.

2. Ensuite, affichez les dernières lignes des journaux du client "bloqué" :

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=not-hello)

3. Appuyez sur Ctrl+C pour quitter.

Vous remarquerez que les deux pods sont capables de se connecter au service hello-server. Cela est dû au fait que vous n'avez pas encore défini de règle de réseau pour limiter l'accès. Dans toutes les fenêtres, vous devriez obtenir des réponses de réussite du serveur.

Hostname: hello-server-7df58f7fb5-nvcvd Hello, world! Version: 1.0.0 Hostname: hello-server-7df58f7fb5-nvcvd Hello, world! Version: 1.0.0 Hostname: hello-server-7df58f7fb5-nvcvd ...

Tâche 5 : Limiter l'accès à l'aide d'une règle de réseau

Vous allez maintenant empêcher les pods non associés au libellé app=hello d'accéder au pod hello-server.

La définition de la règle que vous allez utiliser est contenue dans manifests/network-policy.yaml.

1. Appliquez cette règle en exécutant la commande suivante :

kubectl apply -f ./manifests/network-policy.yaml

Résultat :

networkpolicy.networking.k8s.io/hello-server-allow-from-hello-client created

2. Affichez à nouveau les dernières lignes des journaux du client "bloqué" :

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=not-hello)

Dans les dernières lignes de la fenêtre du client "bloqué", le résultat ressemble désormais à ce qui suit :

wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out ...

La règle de réseau empêche désormais la communication avec hello-server à partir d'un pod sans libellé.

3. Appuyez sur Ctrl+C pour quitter.

Tâche 6 : Limiter les espaces de noms à l'aide de règles de réseau

Dans l'exemple précédent, vous avez défini une règle de réseau qui restreint les connexions en fonction des étiquettes des pods. Il est souvent utile d'ajouter plutôt une étiquette sur des espaces de noms entiers, en particulier lorsque des équipes ou des applications disposent de leur propre espace de noms.

Vous allez maintenant modifier la règle de réseau pour autoriser le trafic uniquement à partir d'un espace de noms désigné, puis vous allez déplacer le pod hello-allowed dans ce nouvel espace de noms.

1. Commencez par supprimer la règle de réseau existante :

kubectl delete -f ./manifests/network-policy.yaml

Résultat :

networkpolicy.networking.k8s.io "hello-server-allow-from-hello-client" deleted

2. Créez la version de l'espace de noms :

kubectl create -f ./manifests/network-policy-namespaced.yaml

Résultat :

networkpolicy.networking.k8s.io/hello-server-allow-from-hello-client created

3. Observez maintenant les journaux du pod hello-allowed-client dans l'espace de noms par défaut :

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=hello)

Vous remarquerez qu'il est désormais impossible de se connecter au service hello-server.

4. Appuyez sur Ctrl+C pour quitter.

5. Enfin, déployez une deuxième copie de l'application hello-clients dans le nouvel espace de noms.

kubectl -n hello-apps apply -f ./manifests/hello-app/hello-client.yaml

Résultat :

deployment.apps/hello-client-allowed created deployment.apps/hello-client-blocked created

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 à déployer la deuxième copie de l'application hello-clients dans le nouvel espace de nom, vous verrez une note s'afficher.

Déployer une deuxième copie de l'application hello-clients dans le nouvel espace de noms

Tâche 7 : Validation

Vérifiez ensuite les journaux des deux nouveaux clients hello-app.

1. Affichez les journaux de l'application associée au libellé "hello" dans l'espace de noms hello-apps en exécutant la commande suivante :

kubectl logs --tail 10 -f -n hello-apps $(kubectl get pods -oname -l app=hello -n hello-apps)

Résultat :

Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp

Les deux clients peuvent se connecter, car à partir de Kubernetes 1.10.x, les règles de réseau ne permettent pas de restreindre l'accès aux pods dans un espace de noms donné. Vous pouvez ajouter des éléments à la liste d'autorisation par étiquette de pod, d'espace de noms, ou ajouter les deux avec un opérateur d'union (par exemple OR). Cependant, il n'est pas encore possible d'ajouter des éléments à la liste d'autorisation par libellé de pod et d'espace de noms avec l'opérateur d'intersection (AND).

2. Appuyez sur Ctrl+C pour quitter.

Tâche 8 : Suppression

Qwiklabs supprimera toutes les ressources utilisées dans le cadre de cet atelier. Toutefois, en conditions réelles, voici comment procéder afin de nettoyer votre environnement pour limiter vos dépenses et utiliser le cloud de manière raisonnée :

1. Déconnectez-vous de l'hôte bastion :

exit

2. Exécutez la commande suivante pour détruire l'environnement :

make teardown

Résultat :

...snip... google_compute_subnetwork.cluster-subnet: Still destroying... (ID: us-east1/kube-net-subnet, 20s elapsed) google_compute_subnetwork.cluster-subnet: Destruction complete after 25s google_compute_network.gke-network: Destroying... (ID: kube-net) google_compute_network.gke-network: Still destroying... (ID: kube-net, 10s elapsed) google_compute_network.gke-network: Still destroying... (ID: kube-net, 20s elapsed) google_compute_network.gke-network: Destruction complete after 26s Destroy complete! Resources: 5 destroyed.

Tâche 9 : Résoudre les problèmes dans votre environnement

Le script d'installation échoue et affiche l'erreur "permission denied" (autorisation refusée) lors de l'exécution de Terraform.

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

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

Il peut arriver que Terraform signale une empreinte non valide lors de la mise à jour de certaines ressources.

Si l'erreur ci-dessous s'affiche, réexécutez simplement la commande.

Félicitations !

Vous avez amélioré la sécurité de Kubernetes Engine en appliquant des restrictions précises aux communications réseau.

Étapes suivantes et informations supplémentaires

• Terraform Google Provider
• Règles de réseau Kubernetes
• Kubernetes Engine – Créer une règle de réseau de cluster
• Kubernetes Engine – Tutoriel sur les règles de réseau
• Kubernetes Engine – Renforcer la sécurité d'un cluster

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 : 25 février 2025

Dernier test de l'atelier : 25 février 2025

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.