Sécuriser une passerelle

Autopilot Standard

---

Cette page explique comment sécuriser une passerelle à l'aide de diverses fonctionnalités de sécurité :

• Règles SSL pour garantir que la passerelle utilise les protocoles et algorithmes sécurisés requis

• Certificats pour sécuriser le trafic client vers passerelle et passerelle vers backends avec TLS

• Stratégie de sécurité Google Cloud Armor pour protéger les services contre les attaques DDoS

• Identity-Aware Proxy (IAP) pour fournir une couche d'authentification et d'autorisation avant d'autoriser l'accès à un service

Pour en savoir plus sur la sécurité des passerelles, consultez la section Sécurité des passerelles.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Activez l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
  Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Conditions requises pour le contrôleur GKE Gateway

• Pour l'environnement standard, GKE version 1.24 ou ultérieure.

• Pour Autopilot, la version 1.26 de GKE ou une version ultérieure.
• Google Cloud CLI version 407.0.0 ou ultérieure.
• L'API Gateway n'est compatible qu'avec les clusters de VPC natif.
• Si vous utilisez les GatewayClasses internes, vous devez activer un sous-réseau proxy réservé.
• Le module complémentaire HttpLoadBalancing doit être activé sur votre cluster.
• Si vous utilisez Istio, vous devez mettre à niveau Istio vers l'une des versions suivantes :
  • 1.15.2 ou ultérieure
  • 1.14.5 ou ultérieure
  • 1.13.9 ou ultérieure
• Si vous utilisez un VPC partagé, vous devez attribuer le rôle Compute Network User au compte de service GKE du projet de service dans le projet hôte.

Restrictions et limitations

Outre les restrictions et limitations du contrôleur GKE Gateway, les limites suivantes s'appliquent spécifiquement à la sécurité de la passerelle :

• Les configurations TLS utilisant un certificat SSL ou un gestionnaire de certificats sur les passerelles ne sont pas compatibles avec GKE version 1.28.4-gke.1083000. Utilisez un secret Kubernetes pour contourner cette version de GKE.

• Vous ne pouvez pas utiliser l'annotation networking.gke.io/certmap avec une clause tls.certificateRefs sur la même ressource de passerelle. Si vous référencez un CertificateMap dans une passerelle, GKE le traitera comme une erreur.

• Le gestionnaire de certificats est compatible avec les certificats autogérés et gérés par Google. Les certificats gérés par Google sont compatibles avec les passerelles régionales (disponibles en version bêta) et les passerelles globales.

• Lorsque vous utilisez des certificats SSL gérés par Google, vous devez créer ces certificats en dehors de GKE avant de les associer à votre passerelle.

• Les certificats SSL gérés par Google ne sont pas compatibles avec les passerelles régionales. Pour en savoir plus sur les méthodes de terminaison TLS pour chaque classe GatewayClass, consultez la page Compatibilité avec TLS GatewayClass.

• Vous ne pouvez pas utiliser le même service comme backend vers une passerelle régionale et globale si vous référencez une stratégie de sécurité de backend Google Cloud Armor dans votre GCPBackendPolicy. Vous devez créer deux règles et services distincts pour ce cas d'utilisation.

• Le contrôleur Gateway n'est pas compatible avec la ressource ManagedCertificate.

• Le contrôleur Gateway n'est pas compatible avec l'annotation networking.gke.io/managed-certificates.

• Le champ appProtocol de la configuration de service n'accepte que des lettres en majuscules pour la valeur du protocole (HTTP, HTTPS ou HTTP2). L'utilisation de lettres en minuscules entraîne l'utilisation du protocole HTTP avec les backends.

Pour obtenir la liste des champs et des fonctionnalités de l'API Gateway compatibles avec les ressources GatewayClass disponibles sur GKE, consultez la page Fonctionnalités de la ressource GatewayClass.

Sécuriser une passerelle à l'aide d'un Secret Kubernetes

Dans cet exemple, vous configurez une passerelle à l'aide d'un Secret Kubernetes.

Stocker un certificat dans un Secret Kubernetes

Vous pouvez utiliser un certificat émis et validé par votre autorité de certification (CA) ou créer un certificat autosigné. Les étapes suivantes utilisent un certificat autosigné.

1. Créer une clé privée :

   openssl genrsa -out PRIVATE_KEY_FILE 2048
   

   Remplacez PRIVATE_KEY_FILE par le nom de votre fichier de clé privée, tel que private-key.pem. Pour en savoir plus, consultez la page Sélectionner ou créer une clé privée.

2. Créez un fichier de configuration OpenSSL :

   cat <<EOF >CONFIG_FILE
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   
   [extension_requirements]
   basicConstraints          = CA:FALSE
   keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName            = @sans_list
   
   [dn_requirements]
   0.organizationName        = example
   commonName                = store.example.com
   
   [sans_list]
   DNS.1                     = store.example.com
   EOF
   

   Remplacez CONFIG_FILE par le nom du nouveau fichier de configuration, par exemple config-file.cnf.

3. Créez un fichier de requête de signature de certificat (CSR) :

   openssl req -new -key PRIVATE_KEY_FILE \
       -out CSR_FILE \
       -config CONFIG_FILE
   

   Remplacez CSR_FILE par le nom du nouveau fichier CSR, tel que cert.pem. Pour en savoir plus, consultez la section Créer un CSR.

4. Signer le CSR :

   openssl x509 -req \
       -signkey PRIVATE_KEY_FILE \
       -in CSR_FILE \
       -out CERTIFICATE_FILE \
       -extfile CONFIG_FILE \
       -extensions extension_requirements \
       -days 30
   

   Remplacez CERTIFICATE_FILE par le chemin d'accès et le nom du fichier généré par la commande, tel que cert-file.pem. Pour en savoir plus, consultez la section Signer le CSR.

5. Créez un secret TLS Kubernetes à l'aide de la clé et du fichier de certificat que vous avez créés :

   kubectl create secret tls store-example-com \
       --cert=CERTIFICATE_FILE \
       --key=PRIVATE_KEY_FILE
   

   GKE enregistre le certificat et la clé en tant que ressource Kubernetes que vous pouvez associer à votre passerelle.

Créer une passerelle et un routage HTTP

1. Enregistrez le manifeste suivant sous le nom external-gateway.yaml :

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
       tls:
         mode: Terminate
         certificateRefs:
         - name: store-example-com
   

   Ce fichier manifeste décrit une passerelle avec les propriétés suivantes :

   • gatewayClassName: gke-l7-global-external-managed : déploie un équilibreur de charge d'application externe global.
   • protocol: HTTPS et port: 443 : requis pour l'activation de TLS.
   • tls : fait référence au secret Kubernetes créé à l'étape précédente.

2. Appliquez le fichier manifeste au cluster :

   kubectl apply -f external-gateway.yaml
   

3. Enregistrez le manifeste suivant sous le nom store-external-route.yaml :

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: store-external
     labels:
       gateway: external-http
   spec:
     parentRefs:
     - name: external-http
     hostnames:
     - "store.example.com"
     rules:
     - backendRefs:
       - name: store-v1
         port: 8080
   

   Ce fichier manifeste décrit un routage HTTP qui correspond au trafic vers store.example.com et l'envoie au service store-v1.

4. Appliquez le fichier manifeste au cluster :

   kubectl apply -f store-external-route.yaml
   

Vérifier la passerelle

Vérifiez que la ressource Gateway fonctionne en envoyant une requête sur Internet.

1. Obtenez l'adresse IP de la passerelle :

   kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
   

   Le résultat ressemble à ce qui suit :

   203.0.113.12
   

   Ce résultat est une adresse IP publique, ce qui signifie que tout client disposant d'un accès Internet peut s'y connecter.

2. Accédez au domaine de la passerelle à l'aide de curl :

   curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert CERTIFICATE_FILE -v
   

   Remplacez les éléments suivants :

   • GATEWAY_IP_ADDRESS : adresse IP de l'équilibreur de charge de la passerelle.
   • CERTIFICATE_FILE : fichier de certificat que vous avez généré. Vous devez enregistrer ce fichier sur la machine que vous utilisez pour vous connecter à la passerelle. Le certificat est requis pour authentifier la passerelle, car celle-ci utilise un certificat autosigné.

   L'option --resolve convertit le nom de domaine en adresse IP de la passerelle, ce qui est nécessaire car le DNS n'est pas configuré pour ce domaine.

   Le résultat ressemble à ce qui suit :

   ...
   * TLSv1.2 (OUT), TLS handshake, Client hello (1):
   * TLSv1.2 (IN), TLS handshake, Server hello (2):
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
   * ALPN, server accepted to use h2
   * Server certificate:
   *  subject: O=example; CN=store.example.com
   *  start date: Apr 19 15:54:50 2021 GMT
   *  expire date: Apr 19 15:54:50 2022 GMT
   *  common name: store.example.com (matched)
   *  issuer: O=example; CN=store.example.com
   *  SSL certificate verify ok.
   ...
   {
     "cluster_name": "gw",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
     "pod_name": "store-v1-84b47c7f58-tj5mn",
     "pod_name_emoji": "😍",
     "project_id": "agmsb-k8s",
     "timestamp": "2021-04-19T16:30:08"
     # Several lines of output omitted here.
   }
   

   Cette sortie inclut un handshake TLS réussi suivi d'une réponse de l'application. La connexion TLS est interrompue au niveau de la passerelle et l'application répond au client de manière sécurisée.

Sécuriser une passerelle à l'aide d'un certificat SSL

Dans cet exemple, vous configurez une passerelle avec un certificat SSL géré par Google.

Remarque :La configuration d'un certificat SSL et de l'annotation networking.gke.io/certmap sur la même ressource Gateway n'est pas une configuration valide, et le contrôleur la traite comme une erreur.

Créer un certificat SSL

1. Créez une ressource SslCertificate globale gérée par Google :

   gcloud compute ssl-certificates create store-example-com \
       --domains=store.example.com \
       --global
   

Créer une passerelle et un routage HTTP

1. Enregistrez le manifeste suivant sous le nom external-gateway.yaml :

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
       tls:
         mode: Terminate
         options:
           networking.gke.io/pre-shared-certs: store-example-com
   

   Ce fichier manifeste décrit une passerelle avec les propriétés suivantes :

   • gatewayClassName: gke-l7-global-external-managed : déploie un équilibreur de charge d'application externe global.
   • protocol:HTTPS et port:443 : requis pour l'activation de TLS.
   • tls.mode:Terminate : interrompt TLS à l'aide de votre certificat SSL.

2. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f external-gateway.yaml
   

3. Enregistrez le fichier manifeste suivant de la ressource HTTPRoute sous le nom store-external-route.yaml :

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: store-external
     labels:
       gateway: external-http
   spec:
     parentRefs:
     - name: external-http
     hostnames:
     - "store.example.com"
     rules:
     - backendRefs:
       - name: store-v1
         port: 8080
   

4. Déployez la ressource HTTPRoute dans votre cluster :

   kubectl apply -f store-external-route.yaml
   

   Le déploiement de la passerelle de la part de GKE peut prendre plusieurs minutes.

Vérifier la passerelle

1. Obtenez l'adresse IP de la passerelle :

   kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
   

   Le résultat ressemble à ce qui suit :

   203.0.113.12
   

   Ce résultat est une adresse IP publique, ce qui signifie que tout client disposant d'un accès Internet peut s'y connecter.

2. Mettez à jour un enregistrement A ou AAAA pour diriger votre domaine vers l'adresse IP de la passerelle.

   Cette étape n'est nécessaire que si vous configurez un certificat SSL géré par Google. Si vous configurez un certificat autogéré, vous pouvez ignorer cette étape.

   Une fois les enregistrements DNS mis à jour, l'utilisation de votre certificat géré par Google de la part de votre équilibreur de charge peut prendre jusqu'à 10 minutes.

3. Vérifiez que la passerelle fonctionne en envoyant une requête sur Internet à l'aide de curl :

   curl https://store.example.com -v
   

   Le résultat ressemble à ce qui suit :

   ...
   * TLSv1.2 (OUT), TLS handshake, Client hello (1):
   * TLSv1.2 (IN), TLS handshake, Server hello (2):
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
   * ALPN, server accepted to use h2
   * Server certificate:
   *  subject: O=example; CN=store.example.com
   *  start date: Apr 19 15:54:50 2021 GMT
   *  expire date: Apr 19 15:54:50 2022 GMT
   *  common name: store.example.com (matched)
   *  issuer: O=example; CN=store.example.com
   *  SSL certificate verify ok.
   ...
   {
     "cluster_name": "gw",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
     "pod_name": "store-v1-84b47c7f58-tj5mn",
     "pod_name_emoji": "😍",
     "project_id": "agmsb-k8s",
     "timestamp": "2021-04-19T16:30:08",
     "zone": "us-west1-a"
   }
   

   Cette sortie inclut un handshake TLS réussi et une réponse de l'application. TLS est correctement interrompu au niveau de la passerelle et l'application répond au client de manière sécurisée.

Sécuriser une passerelle à l'aide du gestionnaire de certificats

Dans cet exemple, vous configurez une passerelle à l'aide du gestionnaire de certificats.

Remarque :La configuration d'un certificat SSL et de l'annotation networking.gke.io/certmap sur la même ressource Gateway n'est pas une configuration valide, et le contrôleur la traite comme une erreur.

Créer un objet Certificate

Passerelle globale

Pour créer une passerelle globale, vous devez référencer une ressource de mappage de certificat qui contient un ou plusieurs certificats. Vous devez créer au moins un certificat et l'ajouter en tant qu'entrée à votre mappage de certificats.

1. Pour créer un certificat, commencez par créer une clé privée et un fichier de certificat.

2. Créez une ressource Certificate en chargeant votre certificat et votre clé autogérés :

   gcloud certificate-manager certificates create store-example-com-cert \
       --certificate-file="cert.pem" \
       --private-key-file="PRIVATE_KEY_FILE"
   

3. Créez un CertificateMap :

   gcloud certificate-manager maps create store-example-com-map
   

4. Créez un CertificateMapEntry qui attribue le certificat à CertificateMap :

   gcloud certificate-manager maps entries create store-example-com-map-entry \
       --map=store-example-com-map \
       --hostname=store.example.com \
       --certificates=store-example-com-cert
   

Passerelle régionale

Pour une passerelle régionale, vous devez créer un objet Certificate qui sera spécifié directement lors de la création de la passerelle. Contrairement à une passerelle globale, vous n'avez pas besoin de créer un CertificateMap auquel les certificats sont attribués.

1. Créez une clé privée et un ficher de certificat.

2. Créez une ressource Certificate en important votre fichier de certificat et votre clé :

gcloud certificate-manager certificates create "CERTIFICATE_NAME" \
    --certificate-file="CERTIFICATE_FILE" \
    --private-key-file="PRIVATE_KEY_FILE" \
    --location="REGION"

Remplacez les éléments suivants :

• CERTIFICATE_NAME : nom de votre certificat, par exemple store-example-com-cert.
• CERTIFICATE_FILE : nom du fichier de certificat, par exemple, cert.pem.
• PRIVATE_KEY_FILE : nom de votre fichier de clé privée, tel que private-key.pem. Pour en savoir plus, consultez la page Sélectionner ou créer une clé privée.
• REGION : nom de la région dans laquelle vous configurez la passerelle, par exemple us-central1.

Créer une passerelle et un routage HTTP

Passerelle globale

Pour créer une passerelle globale, procédez comme suit :

1. Enregistrez le manifeste suivant sous le nom cert-map-gateway.yaml :

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
     annotations:
       networking.gke.io/certmap: store-example-com-map
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
   

   Ce fichier manifeste décrit une passerelle avec les propriétés suivantes :

   • gatewayClassName: gke-l7-global-external-managed : déploie un équilibreur de charge d'application externe global.
   • protocol: HTTPS et port: 443 : requis pour l'activation de TLS.

   Il n'y a pas de section TLS, car TLS est configuré avec le gestionnaire de certificats à l'aide de l'annotation networking.gke.io/certmap.

2. Appliquez le fichier manifeste au cluster :

   kubectl apply -f cert-map-gateway.yaml
   

   Le déploiement de la passerelle de la part de GKE peut prendre plusieurs minutes.

3. Pour créer une ressource HTTPRoute, enregistrez le fichier manifeste suivant sous le nom cert-map-http-route.yaml :

   apiVersion: gateway.networking.k8s.io/v1beta1
   kind: HTTPRoute
   metadata:
     name: foo
     namespace: default
   spec:
     parentRefs:
     - name: external-http
     hostnames:
     - foo.example.com
     rules:
     - matches:
       - path:
           value: /
       backendRefs:
       - name: foo-v1
         port: 8080
   

4. Appliquez le fichier manifeste au cluster :

   kubectl apply -f cert-map-http-route.yaml
   

Passerelle régionale

Lors de la création d'une passerelle régionale, vous pouvez spécifier des certificats gérés par le gestionnaire de certificats et des certificats gérés par Compute Engine.

1. Pour créer une passerelle externe régionale, enregistrez le fichier manifeste suivant sous le nom external-gateway.yaml :

      kind: Gateway
      apiVersion: gateway.networking.k8s.io/v1beta1
      metadata:
        name: gateway
        namespace: corp
      spec:
        gatewayClassName: gke-17-regional-external-managed
        listeners:
        - name: gateway-pre-shared-certmap
          protocol: HTTPS
          port: 443
          tls:
            mode: Terminate
            options:
              networking.gke.io/cert-manager-certs: store-example-com-cert1, store-example-com-cert2
          allowedRoutes:
            kinds:
            - kind: HTTPRoute
            namespaces:
              from: All
   

   Ce fichier manifeste décrit une passerelle avec les propriétés suivantes :

   • gatewayClassName : gke-l7-regional-external-managed : déploie un équilibreur de charge d'application externe régional.
   • protocol: HTTPS et port: 443 : requis pour l'activation de TLS.
   • options :
     • networking.gke.io/cert-manager-certs : certificats gérés par le gestionnaire de certificats.

   Pour créer une passerelle interne régionale, remplacez la valeur de gatewayClassName par gke-17-rilb dans l'exemple précédent. Cette opération déploie un équilibreur de charge d'application interne.

2. Appliquez le fichier manifeste au cluster :

   kubectl apply -f external-gateway.yaml
   

3. Pour créer une ressource HTTPRoute, enregistrez le fichier manifeste suivant sous le nom store-external-route.yaml :

   apiVersion: gateway.networking.k8s.io/v1beta1
   kind: HTTPRoute
   metadata:
     name: store-external
     labels:
       gateway: external-http
   spec:
     parentRefs:
     - name: external-http
     hostnames:
     - "store.example.com"
     rules:
       backendRefs:
       - name: store-v1
         port: 8080
   

   Ce fichier manifeste décrit une route HTTPRoute qui met en correspondance le trafic pour store.example.com et le transfère au service store-v1.

4. Appliquez le fichier manifeste au cluster :

   kubectl apply -f store-external-route.yaml
   

Vérifier la passerelle

1. Obtenez l'adresse IP de la passerelle :

   kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
   

   Le résultat ressemble à ce qui suit :

   203.0.113.12
   

   Ce résultat est une adresse IP publique, ce qui signifie que tout client disposant d'un accès Internet peut s'y connecter.

2. Mettez à jour un enregistrement A ou AAAA pour diriger votre domaine vers l'adresse IP de la passerelle.

   Cette étape n'est nécessaire que si vous configurez un certificat SSL géré par Google. Si vous configurez un certificat autogéré, vous pouvez ignorer cette étape.

   Une fois les enregistrements DNS mis à jour, l'utilisation de votre certificat géré par Google de la part de votre équilibreur de charge peut prendre jusqu'à 10 minutes.

3. Accédez au domaine de la passerelle à l'aide de curl :

   curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert CERTIFICATE_FILE -v
   

   Remplacez les éléments suivants :

   • GATEWAY_IP_ADDRESS : adresse IP de l'équilibreur de charge de la passerelle.
   • CERTIFICATE_FILE : fichier de certificat que vous avez généré. Vous devez enregistrer ce fichier sur la machine que vous utilisez pour vous connecter à la passerelle. Le certificat est requis pour authentifier la passerelle, car celle-ci utilise un certificat autosigné.

   Le résultat ressemble à ce qui suit :

   ...
   * TLSv1.2 (OUT), TLS handshake, Client hello (1):
   * TLSv1.2 (IN), TLS handshake, Server hello (2):
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
   * ALPN, server accepted to use h2
   * Server certificate:
   *  subject: O=example; CN=store.example.com
   *  start date: Apr 19 15:54:50 2021 GMT
   *  expire date: Apr 19 15:54:50 2022 GMT
   *  common name: store.example.com (matched)
   *  issuer: O=example; CN=store.example.com
   *  SSL certificate verify ok.
   ...
   {
     "cluster_name": "gw",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
     "pod_name": "store-v1-84b47c7f58-tj5mn",
     "pod_name_emoji": "😍",
     "project_id": "agmsb-k8s",
     "timestamp": "2021-04-19T16:30:08",
     "zone": "us-west1-a"
   }
   

   Cette sortie inclut un handshake TLS réussi et une réponse de l'application. TLS est correctement interrompu au niveau de la passerelle et l'application répond au client de manière sécurisée.

Sécuriser le trafic de l'équilibreur de charge vers l'application à l'aide de TLS

Vous pouvez chiffrer le trafic de l'équilibreur de charge vers les pods de backend à l'aide du champ ports[].appProtocol. Les champs compatibles avec appProtocol sont : HTTP, HTTPS et HTTP2.

Le fichier manifeste suivant décrit un service qui spécifie que l'équilibreur de charge doit utiliser le trafic HTTPS pour communiquer avec les pods de backend :

apiVersion: v1
kind: Service
metadata:
  name: store-v2
spec:
  selector:
    app: store
    version: v2
  ports:
  - port: 8080
    targetPort: 8080
    appProtocol: HTTPS

Remarque : Le champ appProtocol est sensible à la casse et nécessite que la valeur soit définie en majuscules : HTTP, HTTPS ou HTTP2. Si vous utilisez des lettres minuscules, appProtocol est défini par défaut sur HTTP.

L'équilibreur de charge ne vérifie pas le certificat utilisé par les pods de backend. Il est de votre responsabilité de vous assurer que le certificat utilisé sur les pods de backend est valide.

Remarque : L'élément networking.gke.io/app-protocol précédemment compatible est obsolète. Cette annotation n'est pas compatible avec GKE Gateway Controller.

Sécuriser le trafic client vers l'équilibreur de charge à l'aide de règles SSL

Lorsque vos applications sont exposées via une passerelle externe qui utilise HTTPS, il est important d'utiliser les derniers protocoles ou de spécifier la version minimale de SSL ou TLS. Vous pouvez sécuriser le trafic du client à l'équilibreur de charge à l'aide de règles SSL.

Pour en savoir plus sur les règles SSL pouvant être associées à votre passerelle et sur leur création, consultez la page Configurer des règles SSL pour sécuriser le trafic client vers l'équilibreur de charge.

Protéger vos backends à l'aide de Google Cloud Armor

Les règles de sécurité Google Cloud Armor vous aident à protéger vos applications à équilibrage de charge contre les attaques Web. Après avoir configuré une stratégie de sécurité Google Cloud Armor, vous pouvez la référencer dans une stratégie GCPBackendPolicy appliquée à vos services Kubernetes.

Pour configurer des stratégies Google Cloud Armor avec passerelle, consultez la section Configurer la stratégie de sécurité Google Cloud Armor pour sécuriser vos services de backend.

Authentifier les requêtes sur vos backends à l'aide d'Identity-Aware Proxy

Identity-Aware Proxy vous aide à protéger vos backends contre le trafic indésirable en authentifiant les clients qui envoient des requêtes à vos applications et en appliquant une autorisation de trafic basée sur les rôles. Après avoir activé Identity-Aware Proxy pour GKE, vous pouvez référencer vos identifiants OAuth dans un fichier GCPBackendPolicy appliqué à vos services Kubernetes.

Pour configurer Identity-Aware Proxy avec Gateway, consultez la page Configurer Identity-Aware Proxy.

Étapes suivantes

• En savoir plus sur la sécurité des passerelles.