Tutoriel : Sécuriser GKE Enterprise

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 de shell pour ce 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 :

  1. Assurez-vous de disposer d'une session Cloud Shell active. Vous pouvez lancer Cloud Shell en cliquant sur Activer Cloud Shell Bouton d'activation de Cloud Shell depuis la console Google Cloud dans le projet du tutoriel.

  2. Créez un répertoire dans lequel travailler :

    mkdir tutorial
cd tutorial

  3. Téléchargez le script d'initialisation :

    curl -sLO https://github.com/GoogleCloudPlatform/anthos-sample-deployment/releases/latest/download/init-anthos-sample-deployment.env

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

  5. 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 DSI 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 ?

  1. Accédez à la page Cloud Service Mesh du projet dans lequel vous avez déployé l'exemple de déploiement Anthos :

    Accéder à la page Cloud Service Mesh

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

  3. 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, Cloud Service Mesh indique clairement que le trafic n'est pas chiffré sur votre maillage. Différentes couleurs sont utilisées dans Cloud 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 :

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

  2. Utilisez Config Sync pour récupérer automatiquement les modifications des stratégies du dépôt et ajuster la stratégie Cloud Service Mesh.

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

  1. 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écutez nomos 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 sur anthos-sample-cluster1 :

    kubectl config use-context anthos-sample-cluster1

    Résultat :

    Switched to context "anthos-sample-cluster1".

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

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

  4. 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 commandes git config pour vérifier les valeurs user.email et user.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 de Cloud 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.

  1. 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 est PERMISSIVE, ce qui signifie que les services acceptent le trafic HTTP en texte brut et mTLS.

  2. Modifiez namespaces/istio-system/peer-authentication.yaml pour autoriser uniquement les communications chiffrées entre les services en définissant le mode mTLS sur STRICT :

    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

  3. 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 sur DISABLE, 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

  4. 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 TLS ISTIO_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.

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

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

  3. 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 script init. Cette fonction d'assistance exécute une combinaison de nomos status et de la commande kubectl que vous avez essayée précédemment. Elle surveille le cluster pour détecter les modifications jusqu'à ce que vous appuyiez sur Ctrl+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 Cloud Service Mesh de GKE Enterprise.

    Accéder à la page Cloud 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.

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

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

  3. Validez et transférez les modifications pour appliquer la règle. Vous pouvez utiliser nomos status avec la commande watch pour vérifier que les modifications sont appliquées à votre cluster. Appuyez sur Ctrl+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é.

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

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

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. 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 :

  1. Accédez au répertoire qui héberge les scripts d'installation :

    cd bank-of-anthos/iac/tf-anthos-gke

  2. Supprimez l'exemple et le cluster :

    terraform destroy

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

En savoir plus sur GKE Enterprise