GKE Enterprise offre une plate-forme cohérente pour la création et la livraison de services sécurisés, avec des fonctionnalités de sécurité intégrées à tous les niveaux, qui fonctionnent séparément et ensemble pour fournir une défense en profondeur contre les problèmes de sécurité. Ce tutoriel présente certaines des fonctionnalités de sécurité puissantes de GKE Enterprise avec l'exemple de déploiement Anthos sur Google Cloud. L'exemple de déploiement Anthos déploie un véritable environnement interactif GKE Enterprise avec un cluster GKE, un maillage de services et une application de la banque GKE Enterprise dotée de plusieurs microservices.
Objectifs
Dans ce tutoriel, vous allez découvrir certaines des fonctionnalités de sécurité de GKE Enterprise en effectuant les tâches suivantes :
Appliquer le protocole TLS mutuel (mTLS) au sein de votre maillage de services à l'aide de Config Sync pour garantir une communication sécurisée de bout en bout.
Configurer des garde-fous de sécurité qui garantissent que les pods dotés de conteneurs privilégiés ne sont pas déployés par inadvertance à l'aide de Policy Controller.
Coûts
Le déploiement de l'application Bank of Anthos entraîne des frais à l'usage pour GKE Enterprise sur Google Cloud, comme indiqué sur la page Tarifs, sauf si vous avez déjà souscrit un abonnement.
Vous êtes également responsable des autres coûts Google Cloud engendrés par l'exécution de l'application Bank of Anthos, tels que les frais pour les VM et les équilibreurs de charge Compute Engine.
Nous vous recommandons d'effectuer un nettoyage une fois le tutoriel terminé ou d'explorer le déploiement pour éviter des frais supplémentaires.
Avant de commencer
Ce tutoriel fait suite au tutoriel Découvrir Anthos. Avant de commencer, suivez les instructions fournies sur cette page pour configurer votre projet et installer l'exemple de déploiement Anthos.
Configurer votre environnement Cloud Shell
Dans ce tutoriel, vous allez utiliser la ligne de commande Cloud Shell et l'éditeur pour apporter des modifications à la configuration du cluster.
Pour initialiser l'environnement shell du tutoriel, l'exemple de déploiement Anthos fournit un script qui effectue les opérations suivantes :
Il installe tous les outils de ligne de commande manquants pour travailler de manière interactive et valider les modifications apportées au déploiement :
Définit le contexte Kubernetes pour
anthos-sample-cluster1
Clone le dépôt utilisé par Config Sync pour synchroniser vos modifications de configuration avec votre cluster. Les modifications que vous validez et transférez dans le dépôt en amont sont synchronisées avec votre infrastructure par Config Sync. Il s'agit des bonnes pratiques recommandées pour appliquer les modifications à votre infrastructure.
Pour configurer votre environnement, procédez comme suit :
Assurez-vous de disposer d'une session Cloud Shell active. Vous pouvez lancer Cloud Shell en cliquant sur Activer Cloud Shell dans la console Google Cloud dans le projet du tutoriel.
Créez un répertoire dans lequel travailler :
mkdir tutorial cd tutorial
Téléchargez le script d'initialisation :
curl -sLO https://github.com/GoogleCloudPlatform/anthos-sample-deployment/releases/latest/download/init-anthos-sample-deployment.env
Rafraîchissez le script d'initialisation dans votre environnement Cloud Shell :
source init-anthos-sample-deployment.env
Résultat :
/google/google-cloud-sdk/bin/gcloud /google/google-cloud-sdk/bin/kubectl Your active configuration is: [cloudshell-13605] export PROJECT as anthos-launch-demo-1 export KUBECONFIG as ~/.kube/anthos-launch-demo-1.anthos-trial-gcp.config Fetching cluster endpoint and auth data. kubeconfig entry generated for anthos-sample-cluster1. Copying gs://config-management-release/released/latest/linux_amd64/nomos... \ [1 files][ 40.9 MiB/ 40.9 MiB] Operation completed over 1 objects/40.9 MiB. Installed nomos into ~/bin. Cloned ACM config repo: ./anthos-sample-deployment-config-repo
Remplacez le répertoire par le dépôt de configuration et utilisez-le comme répertoire de travail pour le reste de ce tutoriel :
cd anthos-sample-deployment-config-repo
Appliquer le mode mTLS dans votre maillage de services
En prévision de l'expansion mondiale, votre responsable des technologies de l'information a exigé que toutes les données utilisateur soient chiffrées en transit afin de protéger les informations sensibles et de respecter les lois régionales concernant la confidentialité et le chiffrement des données.
Votre trafic est-il sécurisé actuellement ?
Accédez à la page Anthos Service Mesh du projet dans lequel vous avez déployé l'exemple de déploiement Anthos :
Cliquez sur transactionhistory dans la liste des services. Comme vous l'avez vu dans Découvrir GKE Enterprise, la page des détails du service affiche toutes les données de télémétrie disponibles pour ce service.
Dans le menu Navigation de la page transactionhistory, cliquez sur Services connectés. Dans cette section, vous pouvez afficher les connexions entrantes et sortantes du service. Une icône en forme de cadenas déverrouillé indique qu'une partie du trafic a été observée sur ce port qui n'utilise pas le protocole TLS mutuel (mTLS).
mTLS est un protocole de sécurité qui garantit que le trafic est sécurisé et approuvé dans les deux sens entre les deux services. Chaque service n'accepte que le trafic chiffré provenant de services authentifiés. Comme vous pouvez le constater, Anthos Service Mesh indique clairement que le trafic n'est pas chiffré sur votre maillage. Différentes couleurs sont utilisées dans Anthos Service Mesh pour indiquer si le trafic non chiffré présente une combinaison texte brut et mTLS (orange) ou seulement du texte brut (rouge).
Avec GKE Enterprise, il ne vous reste que quelques étapes à suivre pour entrer en conformité. Plutôt que d'apporter des modifications au niveau du code source, puis de recompiler et de redéployer votre application pour remédier à cette situation, vous pouvez appliquer la nouvelle règle de chiffrement de manière déclarative à l'aide de Config Sync pour déployer automatiquement votre nouvelle configuration à partir d'un dépôt Git central.
Dans cette section, vous allez exécuter les opérations suivantes :
Ajustez la configuration de règle dans votre dépôt Git pour faire en sorte que les services utilisent des communications chiffrées via mTLS.
Utilisez Config Sync pour récupérer automatiquement les modifications des stratégies du dépôt et ajuster la stratégie Anthos Service Mesh.
Vérifiez que la modification de règle s'est produite sur votre cluster configuré pour se synchroniser avec le dépôt.
Confirmer la configuration de Config Sync
La commande
nomos
est un outil de ligne de commande qui vous permet d'interagir avec Config Management Operator et d'effectuer d'autres tâches utiles de Config Sync à partir de votre machine locale ou Cloud Shell. Pour vérifier que Config Sync est correctement installé et configuré sur votre cluster, exécuteznomos status
:nomos status
Résultat :
Connecting to clusters... Current Context Sync Status Last Synced Token Sync Branch Resource Status ------- ------- ----------- ----------------- ----------- --------------- * anthos-sample-cluster1 SYNCED abef0b01 master Healthy
La sortie confirme que Config Sync est configuré pour synchroniser votre cluster avec la branche principale de votre dépôt de configuration. L'astérisque dans la première colonne indique que le contexte actuel est défini sur
anthos-sample-cluster1
. Si cet élément ne s'affiche pas, définissez le contexte actuel suranthos-sample-cluster1
:kubectl config use-context anthos-sample-cluster1
Résultat :
Switched to context "anthos-sample-cluster1".
Vérifiez que vous êtes bien dans la branche
master
:git checkout master
Résultat :
Already on 'master' Your branch is up to date with 'origin/master'.
Vérifiez votre dépôt de configuration en amont :
git remote -v
Résultat :
origin https://source.developers.google.com/.../anthos-sample-deployment-config-repo (fetch) origin https://source.developers.google.com/.../anthos-sample-deployment-config-repo (push)
Assurez-vous que vous vous trouvez toujours dans le répertoire
anthos-sample-deployment-config-repo
, puis exécutez la commande suivante pour vérifier votre configuration git. Cette fonction d'assistance est transmise dans votre environnement par le script d'initialisation et exécute des commandesgit config
pour vérifier les valeursuser.email
etuser.name
existantes de votre configuration git. Si ces valeurs ne sont pas configurées, la fonction définit les valeurs par défaut au niveau du dépôt, en fonction du compte Google Cloud actuellement actif.init_git
Résultat (exemple) :
Configured local git user.email to user@example.com Configured local git user.name to user
Vous êtes maintenant prêt à valider les modifications de règle dans votre dépôt. Lorsque vous transférez ces commits dans votre dépôt en amont (origine), Config Sync garantit que ces modifications sont appliquées au cluster que vous avez configuré pour la gestion.
Mettre à jour une stratégie pour chiffrer tout le trafic du service
La configuration d'Anthos Service Mesh est spécifiée de manière déclarative à l'aide de fichiers YAML. Pour chiffrer l'intégralité du trafic de service, vous devez modifier le fichier YAML qui spécifie les types de trafic que les services peuvent accepter, et le fichier YAML qui spécifie le type de trafic que les services envoient à certaines destinations.
Le premier fichier YAML que vous devez examiner est
namespaces/istio-system/peer-authentication.yaml
, qui est une règle d'authentification au niveau du maillage spécifiant les types de trafic que tous les services du maillage acceptent par défaut.cat namespaces/istio-system/peer-authentication.yaml
Résultat :
apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "default" namespace: "istio-system" spec: mtls: mode: PERMISSIVE
Comme vous pouvez le constater, le mode mTLS de
PeerAuthentication
estPERMISSIVE
, ce qui signifie que les services acceptent le trafic HTTP en texte brut et mTLS.Modifiez
namespaces/istio-system/peer-authentication.yaml
pour autoriser uniquement les communications chiffrées entre les services en définissant le mode mTLS surSTRICT
:cat <<EOF> namespaces/istio-system/peer-authentication.yaml apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "default" namespace: "istio-system" spec: mtls: mode: STRICT EOF
Ensuite, examinez la règle de destination dans
namespaces/istio-system/destination-rule.yaml
. Elle spécifie les règles d'envoi du trafic vers les destinations spécifiées, en indiquant si le trafic est chiffré. Notez que le TLSmode est défini surDISABLE
, ce qui signifie que le trafic est envoyé en texte brut à tous les hôtes correspondants.cat namespaces/istio-system/destination-rule.yaml
Résultat :
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: annotations: meshsecurityinsights.googleapis.com/generated: "1561996419000000000" name: default namespace: istio-system spec: host: '*.local' trafficPolicy: tls: mode: DISABLE
Modifiez
namespaces/istio-system/destination-rule.yaml
pour qu'Istio définisse une règle de trafic qui active TLS pour tous les hôtes correspondants du cluster à l'aide du mode TLSISTIO_MUTUAL
:cat <<EOF> namespaces/istio-system/destination-rule.yaml apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: annotations: meshsecurityinsights.googleapis.com/generated: "1561996419000000000" name: default namespace: istio-system spec: host: '*.local' trafficPolicy: tls: mode: ISTIO_MUTUAL EOF
Effectuer les modifications vers le dépôt
Vous êtes presque prêt à effectuer vos modifications de configuration. Toutefois, nous vous recommandons d'effectuer quelques vérifications avant de valider vos mises à jour.
Exécutez
nomos vet
pour vous assurer que votre configuration est valide :nomos vet
Aucun résultat n'indique qu'il n'y a aucune erreur de validation.
Dès que vous effectuez vos modifications, Config Sync les identifie et les applique à votre système. Pour éviter les résultats inattendus, nous vous recommandons de vérifier que l'état actuel de votre configuration n'a pas changé depuis que vous avez apporté vos modifications. Utilisez
kubectl
pour vérifier quedestinationrule
indique que le mode mTLS est désactivé pour le cluster :kubectl get destinationrule default -n istio-system -o yaml
Résultat :
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule ... spec: host: '*.local' trafficPolicy: tls: mode: DISABLE
Validez et transférez ces modifications dans le dépôt en amont. La commande suivante utilise une fonction d'assistance appelée
watchmtls
qui est transmise dans votre environnement par le scriptinit
. Cette fonction d'assistance exécute une combinaison denomos status
et de la commandekubectl
que vous avez essayée précédemment. Elle surveille le cluster pour détecter les modifications jusqu'à ce que vous appuyiez surCtrl+C
pour quitter. Surveillez l'affichage jusqu'à ce que les modifications soient appliquées et synchronisées sur le cluster.git commit -am "enable mtls" git push origin master && watchmtls
Vous pouvez également consulter les modifications reflétées sur les pages Anthos Service Mesh de GKE Enterprise.
Accéder à la page Anthos Service Mesh
Vous devriez constater que l'icône en forme de cadenas déverrouillé rouge a changé. L'icône en forme de cadenas apparaît en orange (trafic mixte) plutôt qu'en vert (trafic entièrement chiffré), car nous examinons par défaut la dernière heure, avec une combinaison mTLS et texte brut. Si vous effectuez une vérification au bout d'une heure, vous devriez voir un cadenas vert indiquant que vous avez réussi à chiffrer l'ensemble du trafic de service.
Utiliser Policy Controller pour configurer des garde-fous
Votre équipe de sécurité s'inquiète de potentielles attaques de la racine pouvant survenir lors de l'exécution de pods avec des conteneurs privilégiés (conteneurs avec accès racine). Bien que la configuration actuelle ne déploie aucun conteneur privilégié, vous souhaitez vous protéger contre un maximum de vecteurs de menaces susceptibles de compromettre les performances ou, pire encore, les données client.
Malgré les vérifications de l'équipe, il existe un risque que vous soyez involontairement vulnérable aux attaques de la racine par les futures mises à jour de la configuration au cours du processus de livraison continue. Vous décidez de configurer des garde-fous de sécurité pour vous protéger contre ce danger.
Appliquer des garde-fous
Les garde-fous sont des commandes d'administration automatisées conçues pour appliquer des règles qui protègent votre environnement. Policy Controller permet de définir et d'appliquer des règles personnalisées qui ne sont pas couvertes par les objets Kubernetes natifs. Policy Controller contrôle, audite et met en place les garde-fous que vous appliquez en adéquation avec les exigences uniques de sécurité, de conformité et de gouvernance de votre organisation.
Utiliser Policy Controller
Policy Controller est basé sur un moteur de règles Open Source appelé Gatekeeper, qui permet d'appliquer des stratégies chaque fois qu'une ressource du cluster est créée, mise à jour ou supprimée. Ces règles sont définies à l'aide de contraintes issues de la bibliothèque de modèles de Policy Controller ou d'autres modèles de contrainte Gatekeeper.
Policy Controller et la bibliothèque de modèles de Policy Controller sont déjà installés dans l'exemple de déploiement Anthos sur Google Cloud. Cela vous permet de prendre l'avantage lorsque vous mettez en œuvre vos garde-fous en utilisant une contrainte existante pour les conteneurs privilégiés à partir de la bibliothèque.
Appliquer une contrainte de règle pour les conteneurs privilégiés
Pour répondre aux préoccupations de votre équipe de sécurité, vous appliquez la contrainte K8sPSPPrivilegedContainer
.
Cette contrainte empêche l'exécution des pods avec des conteneurs privilégiés.
À l'aide du terminal Cloud Shell, créez un fichier
constraint.yaml
contenant le texte de la contrainte de la bibliothèque, comme suit :cat <<EOF> ~/tutorial/anthos-sample-deployment-config-repo/cluster/constraint.yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sPSPPrivilegedContainer metadata: name: psp-privileged-container spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] excludedNamespaces: ["kube-system"] EOF
Utilisez
nomos vet
pour vérifier que la configuration mise à jour est valide avant de l'appliquer.nomos vet
La commande renvoie un résultat silencieusement tant qu'il n'y a pas d'erreur.
Validez et transférez les modifications pour appliquer la règle. Vous pouvez utiliser
nomos status
avec la commandewatch
pour vérifier que les modifications sont appliquées à votre cluster. Appuyez surCtrl+C
pour quitter la commande watch lorsque vous avez terminé.git add . git commit -m "add policy constraint for privileged containers" git push && watch nomos status
Résultat :
Connecting to clusters... Current Context Sync Status Last Synced Token Sync Branch Resource Status ------- ------- ----------- ----------------- ----------- --------------- * anthos-sample-cluster1 SYNCED f2898e92 master Healthy
Tester votre règle
Après avoir appliqué la règle, vous pouvez la tester en essayant d'exécuter un pod avec un conteneur privilégié.
Dans le terminal Cloud Shell, utilisez la commande suivante pour créer un fichier dans le répertoire du tutoriel,
nginx-privileged.yaml
, avec le contenu de cet exemple de spécification :cat <<EOF> ~/tutorial/nginx-privileged.yaml apiVersion: v1 kind: Pod metadata: name: nginx-privileged-disallowed labels: app: nginx-privileged spec: containers: - name: nginx image: nginx securityContext: privileged: true EOF
Essayez de lancer le pod avec
kubectl apply
.kubectl apply -f ~/tutorial/nginx-privileged.yaml
Résultat :
Error from server ([denied by psp-privileged-container] Privileged container is not allowed: nginx, securityContext: {"privileged": true}): error when creating "~/nginx-privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by psp-privileged-container] Privileged container is not allowed: nginx, security Context: {"privileged": true}
L'erreur indique que le contrôleur d'admission Gatekeeper surveillant votre environnement Kubernetes a appliqué votre nouvelle règle. Cela empêche l'exécution du pod en raison de la présence d'un conteneur privilégié dans la spécification du pod.
Le concept de règles dont les versions sont contrôlées que vous pouvez appliquer pour configurer des garde-fous avec Policy Controller est puissant. En effet, il standardise, unifie et centralise la gouvernance de vos clusters, en appliquant vos stratégies via une surveillance active de votre environnement après le déploiement.
Vous trouverez de nombreux autres types de règles à utiliser comme garde-fous pour votre environnement dans le dépôt Gatekeeper.
Explorer le déploiement plus en détail
Bien que ce tutoriel explique comment utiliser certaines fonctionnalités de sécurité de GKE Enterprise, il vous reste encore beaucoup d'informations à découvrir concernant votre déploiement dans GKE Enterprise. N'hésitez pas à suivre un autre tutoriel ou continuez à explorer vous-même l'exemple de déploiement Anthos sur Google Cloud avant de suivre les instructions de nettoyage de la section suivante.
Effectuer un nettoyage
Une fois que vous avez terminé d'explorer l'application Bank of Anthos, vous pouvez nettoyer les ressources que vous avez créées dans Google Cloud afin qu'elles ne soient plus comptabilisées dans votre quota et qu'elles ne vous soient plus facturées.
Option 1. Vous pouvez supprimer le projet. Toutefois, si vous souhaitez conserver le projet, vous pouvez supprimer le déploiement à l'aide de l'option 2.
Option 2. Si vous souhaitez conserver votre projet actuel, vous pouvez utiliser
terraform destroy
pour supprimer l'exemple d'application et le cluster.
Supprimer le projet (option 1)
Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour ce tutoriel.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Supprimer le déploiement (option 2)
Cette approche supprime l'application Bank of Anthos et le cluster, mais ne supprime pas le projet. Exécutez les commandes suivantes dans Cloud Shell :
Accédez au répertoire qui héberge les scripts d'installation :
cd bank-of-anthos/iac/tf-anthos-gke
Supprimez l'exemple et le cluster :
terraform destroy
Saisissez l'ID du projet lorsque vous y êtes invité.
Si vous envisagez d'effectuer un nouveau déploiement, vérifiez que toutes les conditions sont remplies, comme indiqué dans la section Avant de commencer.
Étapes suivantes
Notre documentation GKE Enterprise contient bien d'autres informations.
Découvrez d'autres tutoriels
Apprenez-en davantage sur la gestion des services avec l'exemple de déploiement Anthos dans le tutoriel Gérer des services avec GKE Enterprise.
Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.
En savoir plus sur GKE Enterprise
Pour en savoir plus sur GKE Enterprise, consultez notre présentation technique.
Découvrez comment configurer GKE Enterprise dans un environnement de production réel en consultant notre guide de configuration.
Découvrez comment exploiter tout le potentiel d'Anthos Service Mesh dans la documentation Anthos Service Mesh.
Pour en savoir plus sur Policy Controller, consultez le guide de Policy Controller.
Pour en savoir plus sur la configuration déclarative et centralisée, et la gestion des règles, consultez la documentation de Config Sync et la documentation de Policy Controller.