GSP480

Aperçu

Dans cet atelier, vous allez découvrir comment améliorer la sécurité de Kubernetes Engine grâce à l'application de 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 client seront provisionnés. Vous allez apprendre comment utiliser une règle de réseau et ajouter des libellés pour autoriser les connexions uniquement à partir d'un des pods client.

Cet atelier a été conçu par les ingénieurs de GKE Helmsman pour vous aider à mieux comprendre l'autorisation binaire GKE. Vous pouvez consulter cette démonstration sur GitHub en cliquant sur ce lien.

• Nous vous invitons tous à enrichir nos ressources.

Architecture

Vous allez définir un cluster privé Kubernetes. 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 comporte un libellé de sorte que la règle de réseau lui permette de se connecter à hello-server.
3. hello-client-blocked : il fonctionne avec le même code que hello-client-allowed, mais le pod comporte un libellé de sorte que la règle de réseau ne l'autorise pas à se connecter à hello-server.

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.

Cloner la démonstration

Clonez les ressources nécessaires pour la réalisation de cet atelier en exécutant la commande suivante :

git clone https://github.com/GoogleCloudPlatform/gke-network-policy-demo.git

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

cd gke-network-policy-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 en place l'atelier

Dans cet atelier, vous allez utiliser les API de service Google Cloud suivants, qui ont été activés 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. 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 par défaut gcloud, exécutez la commande suivante :

make setup-project

Saisissez Y lorsque vous êtes invité à confirmer votre choix.

Cette action va activer les API de service nécessaires et générer un fichier terraform/terraform.tfvars avec les clés suivantes. Vérifiez que les valeurs correspondent à la sortie de gcloud config list en exécutant la commande suivante :

cat terraform/terraform.tfvars

Vérifiez la dernière version de Terraform Google Provider.

Remplacez la version du fournisseur Terraform par la version la plus récente :

sed -i 's/~> 2.10.0/~> 2.14.0/g' terraform/provider.tf

Provisionner le cluster Kubernetes Engine

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

make tf-apply

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.

Validation

Une fois le déploiement terminé, Terraform va générer un message indiquant que la création du cluster a réussi.

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

Vous pouvez également vous assurer que le cluster a bien été créé en vérifiant que les règles de réseau sont activées pour le nouveau cluster.

Vérifiez que networkPolicyConfig.disabled est défini sur false et que networkPolicy.provider est défini sur CALICO en exécutant la commande suivante :

gcloud container clusters describe gke-demo-cluster | grep  -A2 networkPolicy

(Résultat)

  networkPolicyConfig: {}
clusterIpv4Cidr: 10.0.92.0/22
createTime: '2019-04-18T19:41:27+00:00'
--
networkPolicy:
  enabled: true
  provider: CALICO

Tester la tâche terminée

Cliquez sur Check my progress (Vérifier ma progression) pour vérifier la tâche exécutée. Si vous avez réussi à mettre en place l'infrastructure nécessaire à l'aide de Terraform, vous verrez une note d'évaluation s'afficher.

Mettre en place l'infrastructure nécessaire à l'aide de Terraform (Mettre en place l'atelier)

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

gcloud compute ssh gke-demo-bastion

Vous pouvez désormais utiliser les commandes kubectl standards de l'hôte bastion sur le cluster nouvellement créé.

Installer le service 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. 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.extensions/hello-server created

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 Check my progress (Vérifier ma progression) pour vérifier la tâche exécutée. Si vous avez réussi à déployer un service hello-server HTTP simple, vous verrez une note d'évaluation s'afficher.

Installer le service hello-server

Confirmer l'accès par défaut au service hello-server

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

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

Appuyez sur les touches Ctrl + C pour quitter.

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

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

Appuyez sur les touches 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 correctes.

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

Limiter l'accès à l'aide d'une règle de réseau

Vous allez maintenant empêcher aux pods qui ne comportent pas le 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.

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

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 vers hello-server à partir d'un pod sans libellé.

Limiter les espaces de noms à l'aide des 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 libellés des pods. Il est souvent utile d'ajouter un libellé plutôt 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.

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

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

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.

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 Check my progress (Vérifier ma progression) pour vérifier 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 d'évaluation s'afficher.

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

Validation

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

Affichez les journaux de l'application comportant le 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 sont en mesure de se connecter car à partir de Kubernetes 1.10.x, NetworkPolicies ne permet pas de restreindre l'accès aux pods dans un espace de noms donné. Vous pouvez faire des ajouts à la liste blanche par libellé de pod, par libellé d'espace de noms ou par l'union des deux (libellé de pod OU d'espace de noms). Mais il n'est pas encore possible de faire des ajouts d'intersection des deux (par libellé de pod ET d'espace de noms).

Appuyez sur les touches Ctrl + C pour quitter.

Suppression

Qwiklabs supprimera toutes les ressources utilisées dans le cadre de cet atelier. Toutefois, en conditions réelles, afin de nettoyer votre environnement pour limiter vos dépenses et utiliser le cloud de manière raisonnée, vous devrez saisir la commande suivante :

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

exit

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.

Dépannage dans votre environnement

Le script d'installation échoue et affiche le message 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. Assurez-vous 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 lors des opérations Terraform

Il peut arriver que Terraform indique une empreinte non valide lors de la mise à jour de certaines ressources. Si le message d'erreur ci-dessous s'affiche, exécutez simplement à nouveau la commande.

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 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 Securing Applications in Kubernetes Engine - Three Examples, ou consultez ces suggestions :

• Sécurité de Google Kubernetes Engine : autorisation binaire

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

É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

Dernière mise à jour du manuel : 9 juin 2020

Dernier test de l'atelier : 9 juin 2020

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.