De la périphérie au réseau : Exposer les applications de maillage de services via GKE Ingress

Ce tutoriel explique comment combiner Anthos Service Mesh à Cloud Load Balancing pour exposer les applications d'un maillage de services à des clients Internet.

Anthos Service Mesh est un maillage de services géré, basé sur Istio, qui fournit une couche de communication observable, standardisée et à la sécurité renforcée pour les applications. Que vous utilisiez Anthos Service Mesh, Traffic Director ou Istio, un maillage de services fournit une plate-forme de communication globale pour les clients qui communiquent via le maillage. Toutefois, il reste un défi à relever pour connecter des clients situés en dehors du maillage à des applications hébergées dans le maillage.

Vous pouvez exposer une application à des clients de différentes manières selon l'emplacement des clients. Ce tutoriel explique comment exposer une application à des clients en associant Cloud Load Balancing à Anthos Service Mesh afin d'intégrer des équilibreurs de charge à un maillage de services. Ce tutoriel s'adresse aux professionnels avancés qui utilisent Anthos Service Mesh, mais il fonctionne également pour Istio sur Google Kubernetes Engine.

Passerelle d'entrée du réseau maillé

Istio 0.8 a introduit la passerelle d'entrée du maillage, qui fournit un ensemble dédié de proxys dont les ports sont exposés au trafic provenant de l'extérieur du maillage de services. Ces proxys d'entrée du maillage vous permettent de contrôler le comportement d'exposition de la couche 4 séparément du comportement de routage des applications. Les proxys vous permettent également d'appliquer le routage et la règle au trafic externe au réseau maillé avant qu'il n'atteigne un side-car d'application. L'entrée de réseau maillé définit le traitement du trafic lorsqu'il atteint un nœud du maillage, mais les composants externes doivent définir la façon dont le trafic arrive au maillage.

Pour gérer ce trafic externe, vous avez besoin d'un équilibreur de charge externe au maillage. Ce tutoriel utilise Google Cloud Load Balancing provisionné via des ressources GKE Ingress afin d'automatiser le déploiement. L'exemple canonique de cette configuration est un service d'équilibrage de charge externe qui, dans le cas de Google Cloud, déploie un équilibreur de charge TCP/UDP public. Cet équilibreur de charge pointe vers les NodePorts d'un cluster GKE. Ces NodePorts exposent les pods de passerelle d'entrée Istio, qui acheminent le trafic vers les proxys side-car du réseau maillé en aval. Le schéma suivant illustre cette topologie. L'équilibrage de charge pour le trafic privé interne ressemble à cette architecture, à la différence que vous déployez un équilibreur de charge TCP/UDP interne à la place.

Un équilibreur de charge externe achemine les clients externes vers le maillage via des proxys de passerelle d'entrée.

L'utilisation de l'équilibrage de charge transparent de couche 4 avec une passerelle d'entrée du réseau maillé offre les avantages suivants :

  • Cette configuration simplifie le déploiement de l'équilibreur de charge.
  • L'équilibreur de charge fournit une adresse IP virtuelle (VIP) stable, une vérification d'état et une répartition du trafic fiable en cas de modifications du cluster, d'interruptions de nœud ou de pannes de processus.
  • Toutes les règles de routage, l'arrêt TLS et la règle de trafic sont gérés de façon centralisée dans la passerelle d'entrée du maillage.

GKE Ingress et services

Il existe de nombreuses façons d'accorder l'accès aux applications aux clients situés en dehors du cluster. Le tableau suivant répertorie les primitives Kubernetes disponibles pour le déploiement d'équilibreurs de charge sur Google Cloud. Le type d'équilibreur de charge que vous utilisez pour exposer les applications aux clients dépend principalement du type de client externe ou interne, du type de compatibilité de protocole requis et de la disponibilité du maillage de services sur plusieurs clusters GKE ou sur un seul cluster.

Tous les types d'équilibreurs de charge figurant dans le tableau suivant peuvent exposer les applications hébergées sur un réseau maillé, en fonction du cas d'utilisation.

Ressource GKE Équilibreur de charge basé sur le cloud Caractéristiques
Ingress pour l'équilibrage de charge HTTP(S) externe Équilibreur de charge HTTP(S) externe

Proxys de couche 7 dans les points de présence périphériques (PoP) de Google

Adresse IP virtuelle publique

À l'échelle globale

Cluster unique

Ingress pour l'équilibrage de charge HTTP(S) interne Équilibreur de charge HTTP(S) interne

Proxys de couche 7 dans un réseau de cloud privé virtuel (VPC)

Adresse IP virtuelle privée

À l'échelle de la région

Cluster unique

Service externe LoadBalancer Équilibreur de charge TCP/UDP externe

Direct de la couche 4 aux PoP de Google

Adresse IP virtuelle publique

À l'échelle de la région

Cluster unique

Service LoadBalancer interne Équilibreur de charge TCP/UDP interne

Direct de la couche 4 au réseau de routage VPC

Adresse IP virtuelle privée

À l'échelle de la région

Cluster unique

Ingress multicluster (entrée multicluster externe) Équilibreur de charge HTTP(S) externe

Proxys de couche 7 dans les PoP de Google

Adresse IP virtuelle publique

À l'échelle globale

Multicluster

Bien que l'équilibreur de charge par défaut pour Anthos Service Mesh soit l'équilibreur de charge TCP/UDP externe, ce tutoriel se concentre sur l'équilibreur de charge HTTP(S) externe que vous déployez à l'aide de l'équilibrage de charge HTTP(S) externe. L'équilibreur de charge HTTP(S) externe fournit une intégration avec des services de périphérie tels que Identity-Aware Proxy (IAP), Google Cloud Armor et Cloud CDN, ainsi qu'un réseau distribué de proxys de périphérie à l'échelle mondiale. La section suivante décrit l'architecture et les avantages liés à l'utilisation de deux couches d'équilibrage de charge HTTP.

Entrée cloud et entrée du réseau maillé

Le déploiement de l'équilibrage de charge de couche 7 externe en dehors du maillage avec une couche d'entrée du maillage offre des avantages considérables, en particulier pour le trafic Internet. Même si Anthos Service Mesh et les passerelles d'entrée Istio fournissent un routage et une gestion de trafic avancés dans le maillage, certaines fonctions sont mieux adaptées à la périphérie du réseau. L'utilisation de la mise en réseau en périphérie d'Internet via l'équilibrage de charge HTTP(S) externe de Google Cloud peut offrir des avantages significatifs en termes de performances, de fiabilité ou de sécurité par rapport à une entrée basée sur le maillage. En voici quelques exemples :

Cette couche externe de l'équilibrage de charge de couche 7 est appelée entrée cloud, car elle est basée sur des équilibreurs de charge gérés par le cloud et non sur les proxys auto-hébergés utilisés par l'entrée de maillage. La combinaison de l'entrée cloud et de l'entrée de maillage utilise les fonctionnalités complémentaires de l'infrastructure Google Cloud et du maillage. Le schéma suivant montre comment associer l'entrée cloud et l'entrée de maillage afin de créer deux couches d'équilibrage de charge pour le trafic Internet.

L'entrée cloud fait office de passerelle pour le trafic externe vers le maillage via le réseau VPC.

Dans cette topologie, la couche d'entrée cloud récupère le trafic depuis l'extérieur du maillage de services et le dirige vers la couche d'entrée du maillage. La couche d'entrée du maillage dirige ensuite le trafic vers les backends d'application hébergés par le maillage.

Topologie d'entrée dans le cloud et dans le réseau maillé

Cette section décrit les rôles complémentaires de chaque couche d'entrée lorsque vous les utilisez conjointement. Ces rôles ne constituent pas des règles concrètes mais plutôt des consignes qui permettent d'exploiter au mieux les avantages de chaque couche. Il existe probablement des variantes de ce modèle, en fonction de votre cas d'utilisation.

  • Entrée cloud. Lorsqu'elle est associée à une entrée de maillage, la couche d'entrée cloud est mieux adaptée à la sécurité périphérique et à l'équilibrage de charge global. Étant donné que la couche d'entrée cloud bénéficie de fonctions intégrées pour la protection contre les attaques DDoS, les pare-feu cloud, l'authentification et les produits de chiffrement en périphérie, cette couche excelle dans l'exécution de ces services en dehors du maillage. La logique de routage est généralement simple à ce niveau, mais elle peut devenir plus complexe pour les environnements multicluster et multirégionaux. En raison de la fonction essentielle des équilibreurs de charge Internet, la couche d'entrée cloud est souvent gérée par une équipe chargée de l'infrastructure qui dispose d'un contrôle exclusif sur l'exposition et la sécurité des applications sur Internet. Ce contrôle rend cette couche moins flexible et dynamique qu'une infrastructure axée sur le développeur, ce qui peut influer sur les personnes auxquelles vous choisissez d'accorder un accès administrateur et sur la manière dont vous procédez pour accorder un tel accès.
  • Entrée de réseau maillé Lorsqu'elle est associée à un objet d'entrée cloud, la couche d'entrée du maillage permet un routage flexible proche de l'application. En raison de sa flexibilité, l'entrée de maillage est préférable à l'entrée cloud pour une logique de routage complexe et pour une visibilité au niveau de l'application. La séparation entre les couches d'entrée permet également aux propriétaires d'applications de contrôler directement cette couche sans affecter les autres équipes. Lorsque vous exposez des applications de maillage de services via un équilibreur de charge de niveau 4 au lieu d'un équilibreur de charge de niveau 7, vous devez interrompre le protocole TLS client sur la couche d'entrée du maillage au sein du maillage afin de sécuriser les applications.

Vérification de l'état

La vérification de l'état peut être compliquée lorsque vous utilisez deux couches d'équilibrage de charge de couche 7. Vous devez configurer chaque équilibreur de charge pour qu'il vérifie l'état de la couche suivante afin de garantir la réception du trafic. La topologie du schéma suivant montre comment l'entrée cloud vérifie l'état des proxys d'entrée du maillage et comment le maillage, en retour, vérifie l'état des backends d'application.

Le contrôleur d'entrée cloud vérifie l'état de l'entrée du maillage, tandis que l'entrée de maillage vérifie l'état des backends de l'application.

Cette topologie implique les considérations suivantes :

  • Entrée cloud. Dans ce tutoriel, vous allez configurer l'équilibreur de charge Google Cloud via une entrée pour qu'il vérifie l'état des proxys d'entrée du maillage sur leurs ports de vérification d'état exposés. Si un proxy de réseau maillé est indisponible, ou si le cluster, le maillage ou la région n'est pas disponible, l'équilibreur de charge de Google Cloud détecte cette condition et n'envoie pas de trafic au proxy de réseau maillé.
  • Entrée de réseau maillé Dans l'application de maillage, vous effectuez directement les vérifications de l'état des backends afin de pouvoir exécuter l'équilibrage de charge et gérer le trafic localement.

Sécurité

La topologie précédente implique plusieurs éléments de sécurité. L'un des éléments les plus critiques concerne la configuration du chiffrement et du déploiement des certificats. Ingress pour l'équilibrage de charge HTTP(S) externe s'intègre parfaitement aux certificats gérés par Google. Cette intégration provisionne automatiquement les certificats publics, les associe à un équilibreur de charge, puis renouvelle et effectue la rotation des certificats via l'interface GKE Ingress déclarative. Les clients Internet s'authentifient auprès des certificats publics et se connectent à l'équilibreur de charge externe en tant que premier saut dans le cloud privé virtuel (VPC).

Le saut suivant, situé entre Google Front End (GFE) et le proxy d'entrée du maillage, est chiffré par défaut. Le chiffrement au niveau du réseau entre les GFE et leurs backends est appliqué automatiquement. Toutefois, si vos exigences de sécurité impliquent que le propriétaire de la plate-forme conserve la propriété des clés de chiffrement, vous pouvez activer HTTPS entre l'entrée du cluster (GFE) et l'entrée de maillage (l'instance de proxy Envoy). Lorsque vous activez HTTPS pour ce chemin, vous pouvez utiliser un certificat autosigné ou public pour chiffrer le trafic, car le GFE ne s'authentifie pas auprès de celui-ci. Pour éviter une mauvaise gestion des certificats, ne réutilisez pas le certificat public de l'équilibreur de charge public à un autre endroit. Nous vous recommandons plutôt d'utiliser des certificats distincts dans le maillage de services.

Si le maillage de services exige l'utilisation du protocole TLS, tout le trafic est chiffré entre les proxys side-car et l'entrée de maillage. Ce tutoriel n'active pas le protocole HTTPS entre les GFE et la couche d'entrée du maillage, bien que cette architecture puisse s'appliquer à votre environnement. Le schéma suivant illustre le chiffrement HTTPS du client vers l'équilibreur de charge Google Cloud, de l'équilibreur de charge vers le proxy d'entrée du maillage, et du proxy d'entrée vers le proxy side-car.

La sécurité est mise en œuvre à l'aide de certificats gérés en dehors du réseau maillé et de certificats internes à l'intérieur du maillage.

Objectifs

  • Déployer un cluster Google Kubernetes Engine (GKE) sur Google Cloud.
  • Déployer un service Anthos Service Mesh basé sur Istio sur votre cluster GKE.
  • Déployer l'application Boutique en ligne sur le cluster GKE que vous exposez à des clients sur Internet.
  • Configurer GKE Ingress pour arrêter le trafic HTTPS public et le diriger vers des applications hébergées par le maillage de services.

Coûts

Ce tutoriel utilise les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé ce tutoriel, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Consultez la page Effectuer un nettoyage pour en savoir plus.

Avant de commencer

  1. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

    Accéder au sélecteur de projet

  2. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier que la facturation est activée pour votre projet.

  3. Dans Cloud Console, activez Cloud Shell.

    Activer Cloud Shell

    Vous exécutez toutes les commandes de terminal de ce tutoriel depuis Cloud Shell.

  4. Définissez votre projet Google Cloud par défaut :

    export PROJECT=$(gcloud info --format='value(config.project)')
    export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT} --format="value(projectNumber)")
    gcloud config set project ${PROJECT}
    
  5. Clonez le dépôt de code pour obtenir les fichiers de ce tutoriel, puis créez un répertoire de travail :

    mkdir -p ${HOME}/edge-to-mesh
    cd ${HOME}/edge-to-mesh
    export WORKDIR=`pwd`
    

    Une fois le tutoriel terminé, vous pouvez supprimer le répertoire de travail.

Créer des clusters GKE

Les fonctionnalités décrites dans ce tutoriel nécessitent un cluster GKE version 1.16 ou ultérieure.

  1. Dans Cloud Shell, créez un fichier kubeconfig. Cette étape vous permet de ne pas créer de conflit avec votre fichier kubeconfig (par défaut) existant.

    touch edge2mesh_kubeconfig
    export KUBECONFIG=${WORKDIR}/edge2mesh_kubeconfig
    
  2. Définissez des variables d'environnement pour le cluster GKE :

    export CLUSTER_NAME=edge-to-mesh
    export CLUSTER_LOCATION=us-west1-a
    
  3. Créer un cluster GKE

    gcloud container clusters create ${CLUSTER_NAME} \
        --machine-type=e2-standard-4 \
        --num-nodes=4 \
        --zone ${CLUSTER_LOCATION} \
        --enable-stackdriver-kubernetes \
        --enable-ip-alias \
        --workload-pool=${PROJECT}.svc.id.goog \
        --release-channel rapid
    
  4. Assurez-vous que le cluster est en cours d'exécution :

    gcloud container clusters list
    

    Le résultat ressemble à ce qui suit :

    NAME          LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
    edge-to-mesh  us-west1-a  v1.19.9-gke.1400  34.83.193.134  e2-standard-4  v1.19.9-gke.1400  4          RUNNING
    
  5. Connectez-vous au cluster :

    gcloud container clusters get-credentials ${CLUSTER_NAME} --zone ${CLUSTER_LOCATION} --project ${PROJECT}
    

Installer un maillage de services

  1. Dans Cloud Shell, téléchargez le fichier d'installation d'Anthos Service Mesh.

    Créez un fichier de superposition personnalisé pour configurer IstioOperator avec l'annotation NEG :

    cat <<EOF > ingress-backendconfig-operator.yaml
    ---
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:
      components:
        ingressGateways:
          - name: istio-ingressgateway
            enabled: true
            k8s:
              service:
                type: ClusterIP
              serviceAnnotations:
                cloud.google.com/backend-config: '{"default": "ingress-backendconfig"}'
                cloud.google.com/neg: '{"ingress": true}'
    EOF
    

    Cette superposition personnalisée corrige le service istio-ingressgateway avec des annotations personnalisées utilisées par GKE Ingress.

    Ce service comporte les annotations suivantes, qui définissent les paramètres de l'équilibreur de charge Ingress lors de son déploiement :

    • cloud.google.com/backend-config fait référence au nom d'une ressource personnalisée appelée BackendConfig. Le contrôleur Ingress utilise BackendConfig pour définir les paramètres de la ressource Google Cloud BackendService. Utilisez cette ressource à l'étape suivante pour définir des paramètres personnalisés de la vérification d'état de Google Cloud.
    • cloud.google.com/neg: '{"ingress": true}' active les backends Ingress (les proxys d'entrée du maillage, dans ce cas) pour l'équilibrage de charge natif en conteneurs. Pour un équilibrage de charge plus efficace et stable, ces backends utilisent des groupes de points de terminaison du réseau (NEG) plutôt que des groupes d'instances.

    Suivez les étapes de la page Installer Anthos Service Mesh sur GKE afin d'utiliser un script fourni par Google pour installer Anthos Service Mesh. Lorsque vous exécutez le script, incluez l'option suivante:

    --custom_overlay ingress-backendconfig-operator.yaml
    

    Exemple :

    ./install_asm \
        --project_id ${PROJECT} \
        --cluster_name ${CLUSTER_NAME} \
        --cluster_location ${CLUSTER_LOCATION} \
        --mode install \
        --enable_all \
        --custom_overlay ingress-backendconfig-operator.yaml
    
  2. Assurez-vous que tous les déploiements sont opérationnels :

    kubectl wait --for=condition=available --timeout=600s deployment --all -n istio-system
    

    Le résultat ressemble à ce qui suit :

    deployment.apps/istio-ingressgateway condition met
    deployment.apps/istiod-asm-193-2 condition met
    

Installer l'exemple d'application Online Boutique

  1. Dans Cloud Shell, ajoutez un libellé d'espace de noms à l'espace de noms default :

    kubectl label namespace default istio-injection- istio.io/rev=asm-193-2 --overwrite
    

    L'ajout d'un libellé à l'espace de noms namespace indique à Istio d'injecter automatiquement des proxys side-car Envoy lors du déploiement d'une application. Le résultat ressemble à ce qui suit :

    namespace/default labeled
    
  2. Téléchargez les fichiers YAML Kubernetes et Istio pour l'exemple d'application Boutique en ligne :

    curl -LO \
        https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/kubernetes-manifests.yaml
    curl -LO \
        https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/istio-manifests.yaml
    
  3. Déployez l'application Boutique en ligne :

    kubectl apply -f kubernetes-manifests.yaml
    

    Le résultat ressemble à ce qui suit :

    deployment.apps/frontend created
    service/frontend created
    service/frontend-external created
    ...
    
  4. Assurez-vous que tous les déploiements sont opérationnels :

    kubectl get pods
    

    Le résultat ressemble à ce qui suit :

    NAME                                     READY   STATUS    RESTARTS   AGE
    adservice-d854d8786-fjb7q                2/2     Running   0          3m
    cartservice-85b5d5b4ff-8qn7g             2/2     Running   0          2m59s
    checkoutservice-5f9bf659b8-sxhsq         2/2     Running   0          3m1s
    ...
    
  5. Déployez les fichiers manifestes Istio :

    kubectl apply -f istio-manifests.yaml
    

    Le résultat ressemble à ce qui suit :

    virtualservice.networking.istio.io/frontend created
    gateway.networking.istio.io/frontend-gateway created
    virtualservice.networking.istio.io/frontend-ingress created
    serviceentry.networking.istio.io/allow-egress-googleapis created
    serviceentry.networking.istio.io/allow-egress-google-metadata created
    

Déployer GKE Ingress

Dans les étapes suivantes, vous allez déployer l'équilibreur de charge HTTP(S) externe via le contrôleur GKE Ingress. La ressource Ingress automatise le provisionnement de l'équilibreur de charge, de ses certificats TLS et de la vérification de l'état du backend. De plus, vous utilisez Cloud Endpoints pour provisionner automatiquement un nom DNS public pour l'application.

Appliquer les paramètres du service de backend

  1. Dans Cloud Shell, consultez le service istio-ingressgateway pour savoir comment il est déployé avant d'appliquer des personnalisations :

    kubectl get svc -n istio-system istio-ingressgateway
    

    Le résultat affiche les annotations de service de l'installation par défaut.

    NAME                   TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)                                        AGE
    istio-ingressgateway   ClusterIP   10.44.15.44   <none>        15021/TCP,80/TCP,443/TCP,31400/TCP,15443/TCP   5m57s
    

    Plus tôt dans ce tutoriel, vous avez utilisé les profils d'installation d'Anthos Service Mesh ou d'Istio pour déployer istio-ingressgateway en tant que service ClusterIP. Ce profil personnalisé ne déploie pas d'équilibreur de charge TCP/UDP dans le cadre du déploiement du maillage de services, car ce tutoriel expose les applications via des ressources Ingress basées sur HTTP. À ce stade du tutoriel, l'application est inaccessible depuis l'extérieur du cluster, car elle n'est pas exposée.

  2. Enregistrez le manifeste BackendConfig suivant sous le nom ingress-backendconfig.yaml :

    cat <<EOF > ingress-backendconfig.yaml
    apiVersion: cloud.google.com/v1
    kind: BackendConfig
    metadata:
      name: ingress-backendconfig
      namespace: istio-system
    spec:
      healthCheck:
        requestPath: /healthz/ready
        port: 15021
        type: HTTP
      securityPolicy:
        name: edge-fw-policy
    EOF
    

    BackendConfig est une définition de ressource personnalisée (CRD, Custom Resource Definition) qui définit les paramètres du backend pour l'équilibrage de charge Ingress. Pour obtenir la liste complète des paramètres de backend et de frontend que vous pouvez configurer via une GKE Ingress, consultez la page Fonctionnalités Ingress.

    Dans ce tutoriel, le fichier manifeste BackendConfig spécifie des vérifications d'état personnalisées pour les proxys d'entrée du maillage. Anthos Service Mesh et Istio exposent leurs vérifications de l'état du proxy side-car sur le port 15021 au chemin /healthz/ready. Des paramètres de vérification d'état personnalisés sont requis, car le port de diffusion (80) des proxys d'entrée du réseau maillé est différent de celui de la vérification d'état (15021). GKE Ingress utilise les paramètres de vérification d'état suivants dans BackendConfig pour configurer les vérifications de l'état de l'équilibreur de charge Google Cloud. Il existe également une règle de sécurité qui protège le trafic de l'équilibrage de charge de différents types d'attaques de réseau.

    • healthCheck.port définit le port qui reçoit une vérification de l'état par l'équilibreur de charge Google Cloud sur l'adresse IP de chaque pod.
    • healthCheck.requestPath définit le chemin HTTP qui reçoit une vérification de l'état sur le port spécifié.
    • type définit le protocole de la vérification de l'état (dans le cas présent, HTTP).
    • securityPolicy.name fait référence au nom d'une règle de sécurité Cloud Armor.
  3. Déployez ingress-backendconfig.yaml dans votre cluster pour créer la ressource BackendConfig :

    kubectl apply -f ingress-backendconfig.yaml
    

    Le résultat ressemble à ce qui suit :

    backendconfig.cloud.google.com/ingress-backendconfig created
    

    Les paramètres BackendConfig et les annotations du service istio-ingressgateway ne sont appliqués à un équilibreur de charge Google Cloud qu'une fois la ressource Ingress déployée. Le déploiement Ingress associe toutes ces ressources.

Définir des règles de sécurité

Google Cloud Armor fournit une défense contre les attaques DDoS et des règles de sécurité personnalisables que vous pouvez associer à un équilibreur de charge via des ressources Ingress. Dans les étapes suivantes, vous créez une règle de sécurité qui utilise des règles préconfigurées pour bloquer les attaques de script intersites (XSS). Cette règle bloque le trafic correspondant aux signatures d'attaque connues, mais autorise tout autre trafic. Votre environnement peut utiliser des règles différentes en fonction de votre charge de travail.

  1. Dans Cloud Shell, créez une règle de sécurité appelée edge-fw-policy :

    gcloud compute security-policies create edge-fw-policy \
        --description "Block XSS attacks"
    
  2. Créez une règle de sécurité qui utilise les filtres XSS préconfigurés :

    gcloud compute security-policies rules create 1000 \
        --security-policy edge-fw-policy \
        --expression "evaluatePreconfiguredExpr('xss-stable')" \
        --action "deny-403" \
        --description "XSS attack filtering"
    

Le edge-fw-policy a été référencé par ingress-backendconfig à la section précédente. Lorsque la ressource Ingress est déployée, elle associe cette règle de sécurité à l'équilibreur de charge pour protéger les backends du service istio-ingressgateway.

Configurer l'adressage IP et DNS

  1. Dans Cloud Shell, créez une adresse IP statique globale pour l'équilibreur de charge Google Cloud :

    gcloud compute addresses create ingress-ip --global
    

    Cette adresse IP statique est utilisée par la ressource Ingress et permet à l'adresse IP de rester identique, même si l'équilibreur de charge externe est modifié.

  2. Obtenez l'adresse IP statique :

    export GCLB_IP=$(gcloud compute addresses describe ingress-ip --global --format=json | jq -r '.address')
    echo ${GCLB_IP}
    

    Pour créer un mappage stable et lisible avec votre adresse IP Ingress, vous devez disposer d'un enregistrement DNS public. Vous pouvez utiliser le fournisseur DNS de votre choix et l'automatisation de votre choix. Ce tutoriel utilise les points de terminaison au lieu de créer une zone DNS gérée. Les points de terminaison offrent un enregistrement DNS géré par Google gratuit pour une adresse IP publique.

  3. Enregistrez la spécification YAML suivante dans un fichier nommé dns-spec.yaml :

    cat <<EOF > dns-spec.yaml
    swagger: "2.0"
    info:
      description: "Cloud Endpoints DNS"
      title: "Cloud Endpoints DNS"
      version: "1.0.0"
    paths: {}
    host: "frontend.endpoints.${PROJECT}.cloud.goog"
    x-google-endpoints:
    - name: "frontend.endpoints.${PROJECT}.cloud.goog"
      target: "${GCLB_IP}"
    EOF
    

    La spécification YAML définit l'enregistrement DNS public sous la forme frontend.endpoints.${PROJECT}.cloud.goog, où ${PROJECT} est votre numéro de projet unique.

  4. Déployez le fichier dns-spec.yaml dans votre projet Cloud :

    gcloud endpoints services deploy dns-spec.yaml
    

    Le résultat ressemble à ce qui suit :

    Operation finished successfully. The following command can describe the Operation details:
     gcloud endpoints operations describe operations/rollouts.frontend.endpoints.edge2mesh.cloud.goog:442b2b38-4aee-4c60-b9fc-28731657ee08
    
    Service Configuration [2020-04-28r0] uploaded for service [frontend.endpoints.edge2mesh.cloud.goog]
    

    Maintenant que l'adresse IP et les DNS sont configurés, vous pouvez générer un certificat public pour sécuriser l'interface Ingress. GKE Ingress accepte les certificats gérés par Google en tant que ressources Kubernetes. Cela vous permet de les provisionner via des moyens déclaratifs.

Provisionner un certificat TLS

  1. Dans Cloud Shell, enregistrez le manifeste YAML suivant sous le nom managed-cert.yaml :

    cat <<EOF > managed-cert.yaml
    apiVersion: networking.gke.io/v1beta2
    kind: ManagedCertificate
    metadata:
      name: gke-ingress-cert
      namespace: istio-system
    spec:
      domains:
        - "frontend.endpoints.${PROJECT}.cloud.goog"
    EOF
    

    Ce fichier YAML spécifie que le nom DNS créé via les points de terminaison est utilisé pour provisionner un certificat public. Étant donné que Google gère entièrement le cycle de vie de ces certificats publics, ils sont automatiquement générés et renouvelés régulièrement, sans intervention directe de l'utilisateur.

  2. Déployez le fichier managed-cert.yaml dans votre cluster GKE :

    kubectl apply -f managed-cert.yaml
    

    Le résultat ressemble à ce qui suit :

    managedcertificate.networking.gke.io/gke-ingress-cert created
    
  3. Inspectez la ressource ManagedCertificate pour vérifier la progression de la génération du certificat :

    kubectl describe managedcertificate gke-ingress-cert -n istio-system
    

    Le résultat ressemble à ce qui suit :

    Name:         gke-ingress-cert
    Namespace:    istio-system
    Labels:       <none>
    Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                    {"apiVersion":"networking.gke.io/v1beta2","kind":"ManagedCertificate","metadata":{"annotations":{},"name":"gke-ingress-cert","namespace":"...
    API Version:  networking.gke.io/v1beta2
    Kind:         ManagedCertificate
    Metadata:
      Creation Timestamp:  2020-08-05T20:44:49Z
      Generation:          2
      Resource Version:    1389781
      Self Link:           /apis/networking.gke.io/v1beta2/namespaces/istio-system/managedcertificates/gke-ingress-cert
      UID:                 d74ec346-ced9-47a8-988a-6e6e9ddc4019
    Spec:
      Domains:
        frontend.endpoints.edge2mesh.cloud.goog
    Status:
      Certificate Name:    mcrt-306c779e-8439-408a-9634-163664ca6ced
      Certificate Status:  Provisioning
      Domain Status:
        Domain:  frontend.endpoints.edge2mesh.cloud.goog
        Status:  Provisioning
    Events:
      Type    Reason  Age   From                            Message
      ----    ------  ----  ----                            -------
      Normal  Create  44s   managed-certificate-controller  Create SslCertificate mcrt-306c779e-8439-408a-9634-163664ca6ced
    

    Lorsque le certificat est prêt, la valeur Certificate Status est définie sur Active.

Déployer la ressource Ingress

  1. Dans Cloud Shell, enregistrez le fichier manifeste Ingress suivant sous le nom ingress.yaml :

    cat <<EOF > ingress.yaml
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: gke-ingress
      namespace: istio-system
      annotations:
        kubernetes.io/ingress.allow-http: "false"
        kubernetes.io/ingress.global-static-ip-name: "ingress-ip"
        networking.gke.io/managed-certificates: "gke-ingress-cert"
    spec:
      rules:
      - host: frontend.endpoints.${PROJECT}.cloud.goog
        http:
          paths:
          - backend:
              serviceName: istio-ingressgateway
              servicePort: 80
    EOF
    

    Ce fichier manifeste définit une ressource Ingress qui associe toutes les ressources précédentes. Le fichier manifeste spécifie les champs suivants :

    • kubernetes.io/ingress.allow-http: "false" désactive le trafic HTTP sur le port 80 de l'équilibreur de charge Google Cloud. Cela empêche efficacement les connexions de clients avec du trafic non chiffré, car le port 443 n'écoute que le protocole HTTPS et le port 80 est désactivé.
    • kubernetes.io/ingress.global-static-ip-name: "${GCLB_IP}" associe l'adresse IP précédemment créée à l'équilibreur de charge. Cette association permet de créer l'adresse IP séparément de l'équilibreur de charge afin de pouvoir la réutiliser séparément du cycle de vie de l'équilibreur de charge.
    • networking.gke.io/managed-certificates: "gke-ingress-cert" associe cet équilibreur de charge à la ressource de certificat SSL géré par Google créée au préalable.
    • host: frontend.endpoints.${project}.cloud.google.com spécifie l'en-tête d'hôte HTTP que l'adresse IP de l'équilibreur de charge écoute. Le nom DNS est celui que vous utilisez pour promouvoir votre application.
  2. Déployez ingress.yaml dans votre cluster :

    kubectl apply -f ingress.yaml
    
  3. Inspectez la ressource Ingress pour vérifier la progression du déploiement de l'équilibreur de charge :

    kubectl describe ingress gke-ingress -n istio-system
    

    Le résultat ressemble à ce qui suit :

    ...
    Annotations:
      ingress.kubernetes.io/https-forwarding-rule:       k8s2-fs-fq3ng2uk-istio-system-gke-ingress-qm3qqdor
      ingress.kubernetes.io/ssl-cert:                    mcrt-306c779e-8439-408a-9634-163664ca6ced
      networking.gke.io/managed-certificates:            gke-ingress-cert
      kubernetes.io/ingress.global-static-ip-name:  ingress-ip
      ingress.gcp.kubernetes.io/pre-shared-cert:    mcrt-306c779e-8439-408a-9634-163664ca6ced
      ingress.kubernetes.io/backends:               {"k8s-be-31610--07bdde06b914144a":"HEALTHY","k8s1-07bdde06-istio-system-istio-ingressgateway-443-228c1881":"HEALTHY"}
      ingress.kubernetes.io/forwarding-rule:        k8s2-fr-fq3ng2uk-istio-system-gke-ingress-qm3qqdor
      ingress.kubernetes.io/https-target-proxy:     k8s2-ts-fq3ng2uk-istio-system-gke-ingress-qm3qqdor
      ingress.kubernetes.io/target-proxy:           k8s2-tp-fq3ng2uk-istio-system-gke-ingress-qm3qqdor
      ingress.kubernetes.io/url-map:                k8s2-um-fq3ng2uk-istio-system-gke-ingress-qm3qqdor
    ...
    

    La ressource Ingress est prête lorsque les annotations ingress.kubernetes.io/backends indiquent que les backends sont HEALTHY. Les annotations indiquent également les noms des différentes ressources Google Cloud provisionnées, y compris les services de backend, les certificats SSL et les proxys HTTPS.

    Une fois que votre certificat a été provisionné et qu'Ingress est prêt, votre application est accessible.

  4. Cliquez sur le lien suivant :

    echo "https://frontend.endpoints.${PROJECT}.cloud.goog"
    

    L'interface de votre boutique en ligne s'affiche.

    Produits affichés sur la page d&#39;accueil de la boutique en ligne.

  5. Pour afficher les détails de votre certificat, cliquez sur Afficher les informations sur le site dans la barre d'adresse de votre navigateur, puis cliquez sur Certificat (valide).

    La visionneuse de certificats affiche les détails du certificat géré, y compris la date d'expiration et l'auteur.

Vous disposez maintenant d'un équilibreur de charge HTTPS global servant d'interface à votre application hébergée par le maillage de services.

Nettoyer

Une fois que vous avez terminé le tutoriel, vous pouvez nettoyer les ressources que vous avez créées sur Google Cloud afin qu'elles ne vous soient plus facturées. Vous pouvez soit supprimer entièrement le projet, soit supprimer les ressources du cluster, puis le supprimer.

Supprimer le projet

  1. Dans Cloud Console, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Supprimer les ressources individuelles

Si vous souhaitez conserver le projet Cloud que vous avez utilisé dans ce tutoriel, supprimez les différentes ressources :

  1. Supprimez la ressource Ingress :

    kubectl delete -f gke-ingress.yaml
    
  2. Supprimez le certificat géré :

    kubectl delete -f managed-cert.yaml
    
  3. Supprimez l'entrée Endpoints DNS :

    gcloud endpoints services delete "frontend.endpoints.${PROJECT}.cloud.goog"
    

    Le résultat ressemble à ce qui suit :

    Are you sure? This will set the service configuration to be deleted, along
    with all of the associated consumer information. Note: This does not
    immediately delete the service configuration or data and can be undone using
    the undelete command for 30 days. Only after 30 days will the service be
    purged from the system.
    
  4. Lorsque vous êtes invité à continuer, saisissez Y.

    Le résultat ressemble à ce qui suit :

    Waiting for async operation operations/services.frontend.endpoints.edge2mesh.cloud.goog-5 to complete...
    Operation finished successfully. The following command can describe the Operation details:
     gcloud endpoints operations describe operations/services.frontend.endpoints.edge2mesh.cloud.goog-5
    
  5. Supprimez l'adresse IP statique :

    gcloud compute addresses delete ingress-ip --global
    

    Le résultat ressemble à ce qui suit :

    The following global addresses will be deleted:
    
     - [ingress-ip]
    
  6. Lorsque vous êtes invité à continuer, saisissez Y.

    Le résultat ressemble à ce qui suit :

    Deleted
    [https://www.googleapis.com/compute/v1/projects/edge2mesh/global/addresses/ingress-ip].
    
  7. Supprimez le cluster GKE :

    gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION
    

Étape suivante