Le présent document explique aux ingénieurs réseau, plate-forme et de sécurité qui administrent les clusters Kubernetes comment gérer la communication externe entre clusters à l'aide de passerelles d'entrées et de sorties Anthos Service Mesh. Le présent document explique comment utiliser Anthos Service Mesh pour chiffrer et sécuriser le trafic sortant entre des charges de travail déployées sur un cluster Kubernetes et des charges de travail exécutées dans un autre cluster Kubernetes. Les techniques décrites dans le présent document permettent d'utiliser des certificats distincts pour la communication bilatérale chiffrée entre clusters.
Le présent document vient répondre à une forte demande des clients pour l'utilisation d'une autorité de certification racine (CA) spécifique pour la communication entre clusters. Cela peut parfois s'avérer nécessaire dans des marchés hautement réglementés tels que les services financiers ou la santé. Le présent document explique également comment utiliser des points de terminaison autres que les clusters Kubernetes, par exemple des services de validation financière ou une interface API pour les données sensibles. Ces conseils sont particulièrement utiles pour les organisations qui doivent respecter des règles strictes de sécurité et d'audit.
Vous pouvez gérer et utiliser la communication chiffrée sans modifier les charges de travail exécutées dans les clusters. Pour savoir comment configurer vos propres clusters, suivez le tutoriel associé.
Présentation
Les entreprises n'utilisent souvent qu'un seul cluster lorsqu'elles commencent à adopter Kubernetes, la majeure partie des communications étant interne à ce cluster. Par la suite, la quantité d'interactions entre des espaces de noms différents a tendance à augmenter rapidement jusqu'à justifier l'utilisation d'un fournisseur de règles de réseau comme Calico ou Cilium. Toutefois, à mesure que les environnements en conteneurs se développent, il devient de plus en plus important de sécuriser les communications entre les services externes et vos conteneurs exécutés dans des clusters Kubernetes.
Les règles de réseau sont un excellent moyen de gérer les concepts de sécurité traditionnels (par exemple pour créer des règles de pare-feu internes à un cluster), mais elles n'ont qu'une utilité limitée en dehors du cluster. Il est possible de n'autoriser qu'une adresse IP spécifique mais vous n'avez aucun contrôle sur le contenu ou l'identité. Une conception plus versatile est donc nécessaire, notamment pour vous aider à chiffrer le trafic vers d'autres services externes. Le schéma suivant présente une approche possible.
Dans le monde des applications, le chiffrement s'effectue généralement à l'aide du protocole TLS (Transport Layer Security). Cela signifie que vous pouvez chiffrer le trafic à l'aide d'un certificat privé (secret) et d'un certificat public, comme dans le schéma précédent. La partie qui reçoit les données détient le certificat public qui lui permet de vérifier que les données proviennent d'une source sûre. Le trafic Web HTTPS utilise le protocole TLS pour garantir la sécurité et le chiffrement des communications entre un client et un serveur Web. Dans ce cas, le certificat public provient d'un émetteur de confiance aussi appelé autorité de certification (Google Trust Service par exemple) qui fait partie de l'infrastructure à clé publique (PKI). TLS vérifie l'identité du serveur mais pas l'identité du client.
Dans les cas où le client lui-même doit également être vérifié, l'authentification mutuelle (ou mTLS) est nécessaire. L'authentification mutuelle est utilisée lorsque l'expéditeur et le destinataire doivent s'identifier auprès de l'autre partie comme illustré dans le schéma suivant.
Cette méthode est souvent utilisée pour les applications nécessitant une couche de sécurité supplémentaire. Dans le secteur financier ou pour les informations personnelles, les autorités de régulation exigent souvent l'authentification mTLS.
Anthos Service Mesh
Anthos Service Mesh est une solution de maillage de services gérée par Google basée sur l'OSS Istio. Cela signifie qu'elle est entièrement compatible avec l'API Istio. Anthos Service Mesh peut fournir une fonctionnalité mTLS au niveau de la plate-forme plutôt qu'au niveau du code de l'application, ce qui signifie qu'elle peut s'appliquer aux services sans qu'il ne soit nécessaire de recoder chaque service. Les opérations telles que la rotation des certificats font également partie d'Anthos Service Mesh. Ce document traite de l'authentification mTLS et des fonctionnalités de communication externe d'Anthos Service Mesh. Il existe de nombreuses autres fonctionnalités telles que l'injection de pannes, l'équilibrage de charge avancé et le traitement des erreurs.
En acheminant tout le trafic via des proxys side-car (Envoy), des maillages de services tels qu'Anthos Service Mesh permettent de soulager les développeurs des tâches routinières (mais importantes) telles que le chiffrement et la gestion des certificats. En utilisant un proxy transparent, les maillages de services peuvent utiliser de puissantes fonctions L7 telles que le routage des appels HTTP et HTTPS en fonction des informations d'en-tête. Cependant, Anthos Service Mesh permet également l'encapsulation et le chiffrement du trafic, ce qui peut contribuer à améliorer la sécurité.
Exemple de configuration : communication MySQL entre les clusters
Vous pouvez utiliser ce scénario lorsque vous souhaitez disposer d'une communication fiable et sécurisée entre les services de différents clusters. Dans cet exemple, l'application cliente MySQL communique avec une charge de travail de base de données MySQL sur un autre cluster Kubernetes, comme le montre le schéma suivant.
Bien que les maillages de services fonctionnent souvent sous OSI L7, vous pouvez également utiliser certaines de leurs fonctionnalités pour contrôler les communications L4.
Voici ce dont vous avez besoin pour que le concept fonctionne :
- La communication entre les applications et les clusters doit être chiffrée.
- La communication entre le client et le serveur doit être utiliser l'authentification mutuelle (mTLS).
- Il n'est pas nécessaire de modifier les charges de travail client et serveur.
Bien que vous puissiez configurer la base de données MySQL pour qu'elle n'accepte que les connexions chiffrées, cette configuration nécessite de modifier le client de base de données, qui n'est peut-être pas sous votre contrôle.
Il existe plusieurs façons de répondre à ces exigences à l'aide d'Anthos Service Mesh. Une solution consiste à créer un plan de contrôle Istio partagé entre les clusters, permettant ainsi aux services de communiquer entre eux car ils appartiennent à un seul maillage de services logique. Vous pouvez effectuer cette opération pour les clusters GKE compatibles avec Anthos en utilisant Anthos Service Mesh dans une configuration à projet unique ou multiprojet.
Toutefois, comme la communication entre clusters nécessite une chaîne de confiance distincte, vous pouvez utiliser l'approche passerelle de sortie <–> passerelle d'entrée avec l'authentification mutuelle (mTLS).
Les passerelles de sortie et d'entrée sont des proxys Envoy qui résident aux limites du maillage.
Vous pouvez les configurer pour contrôler le flux de trafic entrant et sortant du maillage de services. Cela fonctionne également pour les points de terminaison non-Kubernetes et vous permet d'utiliser différents certificats pour la communication chiffrée.
Configurer la sortie et l'entrée d'Anthos Service Mesh
Dans le scénario précédent, vous gérez une communication sécurisée de cluster à cluster en utilisant des passerelles de sortie et d'entrée entre les clusters respectifs.
Qu'est-ce qu'une passerelle de sortie ?
La sortie correspond au trafic qui sort de votre maillage de services. Une passerelle de sortie fournit un point de sortie contrôlé pour le trafic.
Pour un pod dans lequel le proxy side-car a été injecté, le trafic destiné à un service résidant en dehors du maillage (par exemple, un service d'API public) est acheminé du pod vers le proxy side-car sans configuration supplémentaire. Dans un cluster GKE (et dans la plupart des autres clusters Kubernetes), l'adresse IP du nœud utilise la traduction NAT pour traduire le trafic du proxy side-car qui est ensuite transmis directement vers l'adresse externe du service. Le schéma suivant présente cette configuration.
Dans ce schéma, le client appelle le côté serveur qui représente le service externe. Sur le maillage, ce trafic est sortant. Vous devez donc configurer la passerelle de sortie du côté client (par exemple, le client MySQL).
Vous configurez la passerelle de sortie pour qu'elle transfère l'appel au service externe. Une fois que le service externe a traité la requête et renvoyé la réponse, celle dernière repasse par la passerelle de sortie puis par le proxy client avant d'arriver au pod qui a émis l'appel (par exemple, le client MySQL).
Qu'est-ce qu'une passerelle d'entrée ?
L'entrée correspond au trafic qui entre dans le maillage de services. Une passerelle d'entrée expose les services au monde extérieur (c'est-à-dire, extérieur au maillage de services) et gère la manière dont ces services doivent être accessibles. Elle est comparable à un objet Entrée (Ingress) Kubernetes.
Avec une passerelle d'entrée, vous pouvez définir un seul point d'entrée contrôlé où le trafic entre dans le maillage. Dans un premier temps, le trafic entre par l'intermédiaire de l'équilibreur de charge qui est créé lorsque vous définissez un service de passerelle d'entrée. Ensuite, la requête est transmise au proxy side-car avant d'être transférée vers le pod. Le pod peut traiter la requête et renvoyer la réponse en utilisant la même route en sens inverse. Le schéma suivant présente cette configuration.
Ce trafic est considéré comme du trafic entrant par le maillage de l'autre cluster (VPC 2). Par conséquent, vous devez configurer la passerelle d'entrée côté serveur pour gérer ces appels.
La configuration côté serveur de la passerelle d'entrée transfère l'appel au service interne. Une fois que le service interne a traité la requête, la réponse renvoyée est transmise au client par l'intermédiaire de la passerelle d'entrée.
Combiner les fonctionnalités d'entrée et de sortie pour l'authentification TLS mutuelle
Comme indiqué précédemment, vous devez définir pour le côté client une passerelle de sortie qui agit comme un point de sortie contrôlé pour le maillage de services. Pour vous assurer que le trafic quittant le maillage via la passerelle est chiffré par mTLS, vous pouvez utiliser une technique appelée initiation TLS. Configurez une passerelle de sortie afin qu'elle applique l'initiation TLS pour le trafic vers des services externes
Lorsque le trafic quittant le maillage de services côté client est chiffré, vous devez vous assurer que le côté serveur peut s'identifier auprès du client et déchiffrer le trafic.
Pour cela, vous utilisez la passerelle d'entrée comme point d'entrée unique dans le maillage. Configurez la passerelle d'entrée de sorte à ce qu'elle attende un trafic mutuellement chiffré.
Présentation de l'architecture du maillage
Le schéma suivant décrit les éléments nécessaires à la mise en œuvre de ce concept pour le scénario MySQL, sans modifier quoi que ce soit dans l'application ou sur le serveur.
Dans le VPC 1, vous pouvez voir que le cluster client exécutant le client MySQL accède au serveur. Le serveur se trouve dans le VPC 2.
Du côté client, la configuration est plus lourde que du côté serveur car vous devez effectuer un peu plus de mise en correspondance et de routage du trafic pour vous assurer que l'application utilise la passerelle de sortie. Cependant, cette configuration se prépare à l'avance et vous n'avez à le faire qu'une seule fois. Une fois la mise en œuvre effectuée, la maintenance est relativement facile.
L'avantage de la mise en œuvre de ce concept à l'aide de Kubernetes est que tous les éléments de configuration sont stockés dans des fichiers YAML. Cela signifie que l'intégralité de la construction peut être utilisée sur un dépôt avec versions gérées, ce qui permet d'assurer le suivi des modifications et de les annuler facilement si nécessaire.
Côté client
Cette sous-section porte sur la configuration côté client. Chaque élément du schéma a une fonction distincte dans le maillage afin de contrôler la manière dont le trafic est acheminé via la passerelle de sortie pour atteindre sa destination, le serveur MySQL.
Le routage du trafic ne constitue qu'une partie des fonctionnalités requises. D'autres éléments contrôlent le chiffrement entièrement transparent du trafic afin de garantir que la communication est toujours sécurisée. Les sections suivantes examinent les éléments afin de mieux comprendre leur rôle et leur fonction dans ce scénario.
Entrée de service
Un maillage de services crée son propre registre de services sur un cluster Kubernetes. Le plan de contrôle utilise ce registre pour configurer les proxys side-car en tant que table de routage. Les services exécutés dans Kubernetes sont automatiquement détectés et ajoutés au registre du maillage de services. Les services qui ne s'exécutent pas dans le cluster Kubernetes ne peuvent pas être automatiquement détectés mais peuvent être définis à l'aide d'entrées de service. De cette manière, le client peut utiliser une entrée comme nom d'hôte afin de se connecter à des services externes.
Dans Anthos Service Mesh, des noms de domaine complets (FQDN) sont utilisés pour identifier tous les services. Le nom de domaine complet est la partie la plus importante de cette construction car les certificats sont basés sur le nom d'hôte. Bien qu'il soit possible de modifier le nom de domaine complet, cela signifie que vous devez également générer à nouveau tous les certificats nécessaires.
Pour activer la communication, vous devez configurer le maillage de services de sorte qu'il écoute les appels vers le service externe afin d'acheminer correctement le trafic. Le maillage vous permet de définir une entrée de service qui pointe vers ce service externe.
Cette construction, appelée MESH_EXTERNAL, est idéale pour ces cas d'utilisation. Vous pouvez également spécifier ce que vous recherchez. Comme il s'agit d'un cas d'utilisation L4 et que vous ne pouvez contrôler que l'adresse IP et le port, vous devez indiquer au maillage le protocole et les ports spécifiques : dans ce cas, TCP et le port 3306 (le port standard pour MySQL). En outre, l'homologue côté serveur (tel qu'illustré dans le schéma précédent) écoute sur le port 13306 (la passerelle de sortie du cluster du serveur). Enfin, vous devez indiquer à votre entrée de service qu'elle doit capturer le trafic avec ce tag de port.
L'exemple d'entrée de service YAML suivant illustre cette configuration :
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: mysql-external
spec:
hosts:
- mysql.fqdn.example
location: MESH_EXTERNAL
ports:
- number: 3306
name: tcp
protocol: TCP
- number: 13306
name: tls
protocol: TLS
resolution: DNS
endpoints:
- address: mysql.fqdn.example
ports:
tls: 13306
Avec le champ hosts, vous pouvez définir le nom de domaine complet du service externe ou définir le champ location sur MESH_EXTERNAL. Vous devez également spécifier les valeurs ports utilisées par le service externe, soit 13306 et 3306 dans le cas présent.
13306 est le port exposé de la passerelle d'entrée côté serveur. Il est important de spécifier les deux dans cette entrée de service. Pour le protocole, vous devez spécifier TLS car cette connexion fournit une communication TLS basée de couche 4.
Une fois que vous avez défini l'entrée de service, le maillage peut écouter les appels et modifier le routage en fonction de ces règles.
Les entrées de service doivent être basées sur des entrées DNS ou d'adresse IP existantes, ce qui signifie que le nom DNS doit déjà pouvoir être résolu par un serveur DNS. Par exemple, vous pouvez utiliser un service DNS principal au sein de Kubernetes et y ajouter des entrées qui ne sont pas déjà présentes dans kube-dns. Vous ne pouvez pas utiliser l'entrée de service pour créer une entrée DNS.
Service virtuel
Le service virtuel est une définition utilisée pour affecter les modèles de routage du trafic. Vous utilisez le service virtuel pour vous assurer que les appels du client MySQL vers l'entrée de service sont acheminés vers la passerelle de sortie. Ainsi, vous pouvez configurer un service virtuel pour acheminer le trafic en vous basant sur des facteurs très différents. Dans un cas d'utilisation L7, ces facteurs vont au-delà du routage du trafic. Par exemple, vous pouvez indiquer au service virtuel comment réagir si une cible est inaccessible. Cet exemple utilise un sous-ensemble de cette fonctionnalité afin de router le trafic correspondant uniquement vers la passerelle de sortie en vue d'un traitement ultérieur.
Le schéma précédent montre comment utiliser le service virtuel pour acheminer le trafic du pod par l'intermédiaire du proxy et à destination de la passerelle de sortie, puis de la passerelle de sortie vers le service externe
Vous devez également spécifier le port de votre passerelle de sortie (externe), soit 15443 par défaut. Ce port est défini sur la passerelle de sortie une fois que vous la créez. Vous pouvez choisir n'importe quel autre port libre, mais vous devrez appliquer un correctif à la passerelle pour ouvrir le port choisi.
L'extrait de code suivant montre à quoi pourrait ressembler une telle définition de service virtuel :
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: direct-mysql-through-egress-gateway
spec:
hosts:
- mysql.fqdn.example
gateways:
- istio-egressgateway-mysql
- mesh
tcp:
- match:
- gateways:
- mesh
port: 3306
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: mysql
port:
number: 15443
weight: 100
- match:
- gateways:
- istio-egressgateway-mysql
port: 15443
route:
- destination:
host: mysql.fqdn.example
port:
number: 13306
weight: 100
Le champ hosts contenant l'URL de nom de domaine complet (FQDN) est utilisé pour appliquer les règles de correspondance à l'URL donnée. La première clause match est définie sur le maillage. Il s'agit d'un mot clé réservé qui s'applique à toutes les passerelles de ce maillage. Le premier bloc route est défini pour indiquer au maillage l'action à effectuer en cas de correspondance.
Dans le cas présent, vous envoyez le trafic correspondant vers la passerelle de sortie. Il s'agit de l'emplacement où le port de sortie est défini, en plus de la pondération de la route. Le bloc mentionne également une valeur subset que vous définirez plus tard.
La deuxième clause match est appliquée à la passerelle de sortie. Le deuxième bloc route ajouté à la deuxième clause match configure le maillage pour envoyer le trafic vers l'entrée du cluster de serveur en utilisant le champ host avec le nom de domaine complet de l'entrée et en spécifiant le port 13306.
Pour l'étape suivante, vous devez programmer l'injection de certificat dans la passerelle afin que la communication mTLS fonctionne.
Règles de destination
Maintenant que votre trafic est correctement identifié (entrée de service) et acheminé du pod vers le proxy puis vers la passerelle (service virtuel), l'étape suivante consiste à chiffrer le trafic. Pour le chiffrement du trafic, vous utilisez des règles de destination. Dans un maillage de services, ces règles sont appliquées au trafic après le routage et sont utilisées pour introduire l'équilibrage de charge et d'autres fonctionnalités de gestion du trafic.
Dans le cas présent, vous utilisez des règles de destination pour définir un modèle d'équilibrage de charge standard et pour ajouter des certificats afin d'activer la communication mTLS sur les points de terminaison. Cette étape s'effectue en faisant correspondre le nom de domaine complet du serveur MySQL, exposé via la passerelle d'entrée du cluster de serveur, et en définissant une règle mTLS.
La définition suivante est un exemple de règle de destination :
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: egressgateway-for-mysql
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: mysql
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 15443
tls:
mode: ISTIO_MUTUAL
sni: mysql.fqdn.example
Le champ host correspond au nom de domaine complet du cluster de la passerelle de sortie. La première règle de destination effectue le chiffrement interne du trafic à l'aide du mode ISTIO_MUTUAL (en utilisant le nom de domaine complet de la passerelle de sortie). Dans l'extrait de code, vous définissez un subset utilisé pour créer un équilibrage de charge de type "round-robin" (à tour de rôle) et pour définir (écraser) le port sur 15443. La passerelle de sortie utilise ce port pour envoyer le trafic.
Il est important de définir correctement le champ tls car il définit les règles de maillage interne (ISTIO_MUTUAL). Dans le champ sni (indication du nom du service), ajoutez le nom de domaine complet de la passerelle d'entrée de votre cluster de serveur.
La deuxième règle de destination chiffre le trafic avec les certificats CA racine fournis avant de l'envoyer par l'intermédiaire de la passerelle de sortie :
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: originate-mtls-for-mysql
spec:
host: mysql.fqdn.example
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 13306
tls:
mode: MUTUAL
credentialName: client-credential
sni: mysql.fqdn.example
Le champ host est à nouveau défini sur le nom de domaine complet externe. Le champ trafficPolicy définit le mode de l'équilibreur de charge sur ROUND_ROBIN. Il définit également le port sur 13306 et le mode tls sur MUTUAL, car vous utilisez maintenant les certificats CA racine personnalisés et l'homologue (la passerelle d'entrée qui utilise également tls MUTUAL) doit s'identifier au moyen des mêmes certificats CA racine signés. En utilisant ce port, le trafic peut transiter par le cluster de serveur via sa passerelle d'entrée pour atteindre la base de données MySQL.
Le chiffrement à l'aide des certificats CA racine personnalisés est généralement effectué par le service de détection de secrets Envoy (SDS) à l'aide d'un secret dans Kubernetes contenant les certificats. Ajoutez le nom du secret à la règle de destination à l'aide du champ credentialName.
En résumé, le trafic se comporte maintenant comme suit :
- Il est émis de manière transparente par MySQL vers un nom de domaine complet externe. Ce nom de domaine complet existe dans le registre du maillage de services.
- Il est chiffré à l'aide d'une règle de destination en utilisant les certificats internes du maillage.
- Il est acheminé vers la passerelle par un service virtuel.
- Il est chiffré à l'aide d'une autorité de certification racine personnalisée par une règle de destination (différente de l'autorité de certification de maillage utilisée pour les certificats de maillage).
- Il est transféré via la passerelle de sortie en mode mTLS.
Côté serveur
Dans ce scénario, le côté serveur est plus facile à configurer que le côté client. Vous n'avez besoin que d'une passerelle d'entrée et d'une entrée de service virtuel pour acheminer le trafic vers le serveur MySQL DB, comme le montre le schéma suivant.
Passerelle d'entrée du cluster de serveur
La passerelle d'entrée expose le port 13306. Il peut s'agir de n'importe quel port, mais dans le cas présent un "1" est ajouté devant le port MySQL standard pour l'identifier plus facilement. Pour des raisons de sécurité, nous vous déconseillons d'exposer directement le port MySQL standard (3306) à Internet.
Étant donné que la passerelle d'entrée Istio par défaut n'écoute pas le port 13306, vous devez ajouter cette fonctionnalité. L'exemple d'extrait de code suivant renvoie le port 13306 à la passerelle :
[{
"op": "add",
"path": "/spec/ports/0",
"value": {
"name": "tls-mysql",
"protocol": "TCP",
"targetPort": 13306,
"port": 13306
}
}]
Vous pouvez stocker ce code dans un fichier JSON et l'utiliser avec la commande "patch" kubectl afin de l'appliquer au service de passerelle d'entrée.
Pour traiter correctement le trafic, la passerelle d'entrée doit être configurée en mode MUTUAL.
À ce stade, la passerelle d'entrée déchiffre le trafic entrant en utilisant le certificat de son stockage d'identifiants puis l'envoie dans le maillage où les certificats internes de maillage sont utilisés pour rechiffrer le trafic. L'extrait de code suivant montre comment procéder :
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: gateway-mysql
spec:
selector:
istio: ingressgateway # Istio default gateway implementation
servers:
- port:
number: 13306
name: tls-mysql
protocol: TLS
tls:
mode: MUTUAL
credentialName: mysql-credential
hosts:
- "mysql.fqdn.example"
Dans cet exemple, la passerelle d'entrée Istio standard est utilisée dans le champ selector. À l'aide du champ servers, vous pouvez définir les valeurs de port number (13306) et protocol (TLS) auxquelles l'entrée doit s'attendre.
Il est important de donner un nom unique au port.
Définissez tls et fournissez un secret contenant le certificat signé par la même autorité de certification racine que celle utilisée avec la passerelle de sortie en utilisant le champ credentialName.
Le certificat doit être stocké dans un secret Kubernetes.
Enfin, vous souhaitez faire correspondre le trafic à destination du nom de domaine complet de la base de données MySQL. La résolution de nom pour ce nom de domaine complet définie sous hosts doit être définie sur l'adresse IP publique de la passerelle d'entrée.
Service virtuel du cluster de serveur
Une fois que le trafic a atteint le réseau maillé via le port 13306 à partir de la passerelle de sortie du cluster client (émetteur), vous devez identifier ce trafic et vous assurer qu'il atteint le serveur de base de données MySQL. Pour cela, définissez un service virtuel :
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: mysql-virtual-service
spec:
hosts:
- "mysql.fqdn.example"
gateways:
- gateway-mysql
tcp:
- route:
- destination:
port:
number: 3306
host: mysql.default.svc.cluster.local
Pour envoyer le trafic vers le service MySQL DB, vous devez vérifier à nouveau le nom de domaine complet de l'hôte en utilisant le champ hosts. En outre, vous devez utiliser le champ gateways pour configurer l'emplacement où appliquer cette définition de service virtuel. Il s'agit de l'objet de passerelle que vous avez défini dans le fichier YAML précédent. Définissez le champ tcp (car il s'agit de trafic L4) puis définissez le champ route de sorte qu'il pointe vers le service MySQL DB Kubernetes. Vous devez spécifier le nom du service sous le champ host en utilisant le nom de domaine complet interne du cluster Kubernetes.
La base de données MySQL peut recevoir les requêtes du client sur le port 3306. Le trafic transite par le proxy side-car du serveur de base de données MySQL. Pour le serveur MySQL DB, il ressemble à une requête locale non chiffrée pour l'accès à la base de données.
Une fois que le serveur répond à l'appel, le trafic revient au client par la même route. Côté client, tout se déroule comme si une base de données locale venait de répondre à l'appel.
Le trafic est chiffré trois fois à l'aide de différents certificats de transit du client au serveur, ce qui permet de sécuriser la communication entre le client et le serveur.
La première fois, le trafic est chiffré ou déchiffré avec des certificats utilisant l'autorité de certification de maillage alors qu'il se trouve à l'intérieur du maillage côté client.
La deuxième fois, le trafic est chiffré lors de sa sortie du maillage au niveau de la passerelle de sortie, en utilisant un certificat provenant d'une autorité de certification racine personnalisée. Le trafic est ensuite authentifié et déchiffré sur la passerelle d'entrée à l'aide d'un certificat signé par la même autorité de certification racine personnalisée.
La troisième et dernière fois, le trafic est chiffré ou déchiffré à l'intérieur du maillage au niveau du côté serveur lorsqu'il transite par la passerelle d'entrée du serveur MySQL. Ici aussi (car il s'agit d'un réseau maillé interne), les certificats de l'autorité de certification de maillage sont utilisés.
Dans ce scénario, la communication entre les deux clusters devait être chiffrée à l'aide de l'autorité de certification racine mentionnée. En appliquant cette configuration, il est possible de gérer cette partie séparément et indépendamment des certificats internes du maillage et de l'application elle-même.
Grâce à cette étape supplémentaire, cette configuration vous permet d'alterner régulièrement ces certificats en toute simplicité, sans modifier l'autorité de certification de maillage des clusters Kubernetes respectifs.
Étape suivante
- Suivez le tutoriel associé.
- Consultez le guide de renforcement de la sécurité sur GKE.
- Découvrez comment gérer la configuration et les règles de manière unifiée sur l'ensemble de votre infrastructure avec Config Management.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.