Sécurité des passerelles

Cette page décrit différentes méthodes pour sécuriser les passerelles dans Google Kubernetes Engine (GKE). Vous pouvez également apprendre à sécuriser une passerelle.

Fonctionnement de la sécurité de la passerelle

Une passerelle représente l'interface d'un équilibreur de charge. Il existe deux chemins que vous pouvez sécuriser avec l'authentification et le chiffrement pour les passerelles :

  • Client à passerelle : le trafic provient du client et s'arrête au niveau de la passerelle.
  • Passerelle vers pod : le trafic provient de la passerelle et s'arrête aux pods de backend.

Le schéma suivant illustre les deux chemins d'authentification et de chiffrement des passerelles :

Cette page explique comment sécuriser le chemin d'accès du client vers la passerelle à l'aide de certificats importés et gérés au niveau de la passerelle. Pour savoir comment sécuriser le trafic entre une passerelle et un pod, consultez la section Sécuriser le trafic de l'équilibreur de charge vers les applications à l'aide de TLS.

Avantages

Vous pouvez sécuriser une application de différentes manières à l'aide de l'API Gateway, qui offre flexibilité à différents rôles interagissant avec la passerelle.

Qui est propriétaire du domaine et de la configuration TLS ?

Le modèle de l'API Gateway introduit deux rôles qui utilisent ou déploient des passerelles :

  • Administrateur de la plate-forme : l'opérateur de cluster est l'administrateur de clusters entiers. Il gère les stratégies, l'accès au réseau et les autorisations des applications.
  • Développeur d'application : le développeur d'applications définit leur configuration d'application et de service.

Le schéma suivant montre les champs des ressources Gateway et HTTPRoute qui influencent la propriété TLS et la propriété du domaine pour deux applications, store-v1 et store-v2.

Dans le schéma, l'opérateur de cluster contrôle :

  • Les domaines que les développeurs d'applications peuvent utiliser pour leurs applications dans chaque espace de noms.
  • Les certificats spécifiques qui mettent fin à différents domaines.
  • Certificats fournis par le propriétaire de la passerelle.
  • Indique si les propriétaires HTTPRouter peuvent spécifier leurs propres noms d'hôte pour la génération de certificats.

Les développeurs d'applications contrôlent le nom d'hôte qui génère un certificat, si la définition de la passerelle le permet.

Cette séparation des tâches opérationnelles permet aux développeurs d'applications de déployer et de gérer leur propre HTTPRoute pour un contrôle plus distribué, et permet aux administrateurs de plate-forme de déployer et de gérer des passerelles pour un contrôle centralisé de TLS.

Gestion des certificats de passerelle

Vous pouvez sécuriser les passerelles à l'aide de l'une des méthodes suivantes :

Si vous utilisez des secrets Kubernetes ou des ressources SslCertificate de l'API Compute Engine, vous pouvez associer au maximum 15 certificats à une seule passerelle.

Le gestionnaire de certificats vous permet d'associer jusqu'à 10 000 000 de certificats par équilibreur de charge, si vous demandez une augmentation de quota.

Pour en savoir plus sur les certificats SSL Google Cloud, consultez la page Présentation des certificats SSL.

Secrets Kubernetes

La spécification de l'API Gateway est compatible avec les secrets Kubernetes permettant de stocker et d'associer des certificats à des passerelles. Vous pouvez associer un ou plusieurs secrets Kubernetes à une passerelle à l'aide du champ Gateway.spec.tls.certificateRef.

Les ressources de passerelle sécurisées via des secrets Kubernetes présentent les exigences suivantes :

  • Vous devez définir l'écouteur port et protocol de la passerelle sur 443 et HTTPS.
  • Vous devez définir le champ listener.tls.mode sur Terminate.
  • Vous devez référencer les identifiants TLS dans le bloc listeners.tls.

Les ressources de passerelle sécurisées à l'aide de secrets Kubernetes présentent les limitations suivantes :

  • Seuls les écouteurs HTTPS interrompent le trafic à l'aide des secrets spécifiés, bien que vous puissiez spécifier plusieurs écouteurs avec une combinaison de HTTP et HTTPS.
  • Si plusieurs écouteurs utilisent HTTPS sur la même passerelle, chaque écouteur doit avoir un nom d'hôte unique.
  • Vous ne pouvez omettre qu'un seul nom d'hôte ou attribuer * pour chaque paire port/protocole.
  • Vous ne pouvez attribuer qu'un seul certificat par défaut pour chaque passerelle.

Pour sécuriser une passerelle à l'aide d'un secret Kubernetes, consultez la page Sécuriser une passerelle à l'aide d'un secret Kubernetes.

Certificats SSL

Les certificats SSL stockent et fournissent des certificats aux équilibreurs de charge.

Un certificat SSL peut être autogéré ou géré par Google.

Pour en savoir plus sur les différences entre ces deux types de certificats, consultez la présentation des certificats SSL.

Le champ d'application et l'emplacement du certificat SSL doivent correspondre au champ d'application et à l'emplacement de la passerelle qui l'utilise.

Par exemple, un certificat SSL global ne peut pas être utilisé par une passerelle régionale.

Le tableau suivant répertorie les exigences de champ d'application et d'emplacement des certificats SSL pour chaque GatewayClass :

GatewayClass Champ d'application du certificat SSL Emplacement du certificat SSL
gke-l7-global-external-managed Certificat SSL global Monde
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc
gke-l7-regional-external-managed Certificat SSL régional Doit être la même région que celle de la ressource Gateway
gke-l7-regional-external-managed-mc
gke-l7-rilb
gke-l7-rilb-mc
Les certificats SSL gérés par Google ne sont pas compatibles avec les passerelles régionales.

Pour savoir comment sécuriser une passerelle à l'aide d'un certificat SSL, consultez la page Sécuriser une passerelle à l'aide d'un certificat SSL.

Gestionnaire de certificats

Le gestionnaire de certificats est un emplacement centralisé pour gérer vos certificats TLS.

Lorsque vous sécurisez une passerelle à l'aide du gestionnaire de certificats, vous pouvez effectuer les opérations suivantes :

  • Référencez un CertificateMap directement à partir d'une passerelle que vous avez créée dans le gestionnaire de certificats.
  • Gérez vos propres certificats.
  • Améliorer les temps de propagation des certificats
  • Utilisez Cloud Monitoring pour les certificats expirés et la propagation des certificats.

Le gestionnaire de certificats est compatible avec les certificats SSL autogérés et gérés par Google.

Pour savoir comment sécuriser une passerelle à l'aide du gestionnaire de certificats, consultez la page Sécuriser une passerelle à l'aide du gestionnaire de certificats.

Compatibilité avec TLS GatewayClass

Le tableau suivant décrit les méthodes de terminaison TLS acceptées par GKE pour chaque GatewayClass :

GatewayClass gke-l7-global-external-managed
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc 		gke-l7-regional-external-managed
gke-l7-regional-external-managed-mc
gke-l7-rilb
gke-l7-rilb-mc
TLS client vers passerelle Compatible Compatible
Passerelle vers TLS backend Compatible Compatible
Ressource de certificat Google Cloud Certificat SSL global
CertificateMap		 Certificat SSL régional
Certificats autogérés avec les secrets Kubernetes Compatible Compatible
Certificats SSL Compute Engine autogérés Compatible Compatible
Certificats SSL Compute Engine gérés par Google Compatible Non compatible
Certificats SSL autogérés avec le gestionnaire de certificats Compatible Compatible
Certificats SSL gérés par Google avec le gestionnaire de certificats Compatible Compatible (Bêta)

Étape suivante