Utiliser Private Service Connect pour publier et consommer des services avec GKE

1. Introduction

Private Service Connect permet à un producteur de services de proposer des services en mode privé à un client. Private Service Connect offre les avantages suivants :

  • Un réseau VPC producteur de services peut prendre en charge plusieurs clients de service.
  • Chaque client se connecte à une adresse IP interne qu'il a définie. Private Service Connect effectue une traduction d'adresse réseau (NAT) pour acheminer la requête vers le producteur de services.

45b90d50690dd111.png

Figure 2. Private Service Connect utilise des points de terminaison et des rattachements de service pour permettre aux clients de services d'envoyer du trafic depuis le réseau VPC du client vers les services du réseau VPC du producteur de services (cliquez pour agrandir).

Points abordés

  • Avantages de Private Service Connect
  • Concepts clés pour les clients de services
  • Concepts clés pour les producteurs de services
  • Créer un environnement de production
  • Exposer le service (environnement du producteur) via un rattachement de service
  • Créer un environnement consommateur
  • Créer une règle de transfert dans le réseau consommateur
  • Valider l'accès des consommateurs
  • Activer le contrôle des accès aux règles
  • Utiliser une règle de pare-feu de sortie pour bloquer l'accès à une règle de transfert de consommateur

Prérequis

  • Connaissances en matière de déploiement de clusters et de services GKE
  • Connaissance des équilibreurs de charge internes
  • Vous êtes capable de créer des VPC dans deux projets.
  • Possibilité de créer un cluster GKE

2. Avantages de Private Service Connect

Le service Private Service Connect présente plusieurs avantages par rapport à l'appairage de réseaux VPC :

Meilleur contrôle de l'espace d'adresses IP privées

  • En tant que client de service, vous pouvez contrôler l'adresse IP privée utilisée pour vous connecter au service géré auquel vous souhaitez accéder.
  • En tant que consommateur de services, vous n'avez pas besoin de vous soucier de la réservation de plages d'adresses IP privées pour les services de backend utilisés dans votre VPC. Il vous suffit de choisir une adresse IP de votre propre sous-réseau pour vous connecter aux services du producteur.
  • En tant que producteur de services, vous pouvez choisir de déployer un modèle mutualisé, dans lequel votre VPC héberge des services utilisés par les réseaux VPC de plusieurs clients. Les clients dont les plages de sous-réseaux se chevauchent ne posent plus de problème.
  • En tant que fournisseur de services, vous pouvez faire évoluer votre service vers le nombre d'instances de VM requis, sans avoir à contacter votre client pour obtenir davantage d'adresses IP.

Sécurité et isolation améliorées

  • En tant que client de service, vous êtes le seul à pouvoir contacter le producteur de service. Cette connectivité unidirectionnelle simplifie drastiquement la configuration des pare-feu, mais réduit également le risque de trafic sauvage en provenance du producteur de services.
  • En tant que producteur de services, vous n'avez pas besoin de modifier vos règles de pare-feu en fonction des plages de sous-réseau du VPC du consommateur. Il suffit de créer des règles de pare-feu pour la plage d'adresses IP NAT configurée pour le service.

Meilleure évolutivité

  • PSC permet une conception hautement évolutive en prenant en charge des milliers de clients. Il permet également aux producteurs de services de proposer des services mutualisés ou à locataire unique hautement évolutifs.
  • En tant que client de services utilisant Private Service Connect, vous pouvez créer des ressources selon vos besoins dans votre VPC. L'échelle de ce processus n'est pas affectée par le nombre de ressources de ce type créées dans le VPC du producteur.

3. Concepts clés pour les clients de services

Vous pouvez utiliser des points de terminaison Private Service Connect pour consommer des services en dehors de votre réseau VPC. Les clients de services créent des points de terminaison Private Service Connect qui se connectent à un service cible.

Points de terminaison

Vous utilisez des points de terminaison Private Service Connect pour vous connecter à un service cible. Les points de terminaison disposent d'une adresse IP interne dans votre réseau VPC et sont basés sur la ressource de règle de transfert.

Vous envoyez du trafic au point de terminaison qui le transfère ensuite à des cibles extérieures à votre réseau VPC.

Cibles

Les points de terminaison Private Service Connect ont une cible qui est le service auquel vous souhaitez vous connecter :

  • Un bundle d'API :
  • Toutes les API : la plupart des API Google
  • VPC-SC : API compatibles avec VPC Service Controls
  • Un service publié dans un autre réseau VPC. Ce service peut être géré par votre propre organisation ou par un tiers.

Service publié

Pour connecter votre point de terminaison au service d'un producteur de services, vous avez besoin du rattachement de service associé au service. L'URI du rattachement de service a le format suivant : projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME

4. Concepts clés pour les producteurs de services

Pour rendre un service disponible pour les clients, créez un ou plusieurs sous-réseaux dédiés à utiliser pour la traduction d'adresses réseau (NAT) des adresses IP des clients. Vous créez ensuite un rattachement de service qui fait référence à ces sous-réseaux.

Sous-réseaux Private Service Connect

Pour exposer un service, le producteur de services crée d'abord un ou plusieurs sous-réseaux dont l'objet est Private Service Connect.

Lorsqu'une requête est envoyée depuis un réseau VPC client, l'adresse IP source du client est traduite à l'aide de la traduction NAT source (SNAT) de manière à obtenir une adresse IP sélectionnée dans l'un des sous-réseaux Private Service Connect.

Si vous souhaitez conserver les informations relatives à l'adresse IP de la connexion client, consultez la page Afficher les informations de connexion client.

Ces sous-réseaux ne peuvent pas être utilisés pour des ressources telles que des instances de VM ou des règles de transfert. Les sous-réseaux ne sont utilisés que pour fournir les adresses IP de SNAT des connexions client entrantes.

Le sous-réseau Private Service Connect doit contenir au moins une adresse IP pour 63 VM client afin d'allouer 1 024 tuples sources pour la traduction d'adresses réseau.

La taille minimale d'un sous-réseau Private Service Connect est de /24.

Rattachements de service

Les producteurs de services exposent leur service via un rattachement de service.

  • Pour exposer un service, un producteur de services crée un rattachement de service qui fait référence à la règle de transfert de l'équilibreur de charge du service.
  • Pour accéder à un service, un client de services crée un point de terminaison qui fait référence au rattachement de service.

Préférences de connexion

Lorsque vous créez un service, vous choisissez comment le rendre disponible. Vous disposez de deux options :

  • Accepter automatiquement les connexions pour tous les projets : tout consommateur de services peut configurer un point de terminaison et se connecter automatiquement au service.
  • Accepter les connexions pour les projets sélectionnés : les clients de services configurent un point de terminaison pour se connecter au service, et le producteur de services accepte ou refuse les requêtes de connexion.

Conditions requises et limites

  • Des limites s'appliquent à Private Service Connect.
  • Vous pouvez créer un rattachement de service dans GKE version 1.21.4-gke.300 et ultérieures.
  • Vous ne pouvez pas utiliser le même sous-réseau dans plusieurs configurations de rattachement de service.
  • Vous devez créer un service GKE qui utilise un équilibreur de charge TCP/UDP interne.

5. Environnement de test

Le réseau du consommateur se compose d'une adresse IP statique utilisée pour envoyer des requêtes au producteur de services, en plus du rattachement de service cible qui correspond au rattachement de service du producteur (service publié).

1ce5607c0c56d77d.jpeg

Examinons maintenant le réseau de producteurs. Notez que le réseau de producteurs n'est pas mappé au réseau de consommateurs. En revanche, il contient un rattachement de service (service publié) utilisé par le consommateur pour les services. La pièce jointe de service du producteur est exposée par un équilibreur de charge interne (ILB) de couche 4 GKE Ingress (service publié), ce qui permet la communication avec les pods GKE et les applications associées.

Le sous-réseau NAT est utilisé lorsqu'une requête est envoyée depuis un réseau VPC client. L'adresse IP source du client est alors traduite à l'aide de la traduction NAT source (SNAT) de manière à obtenir une adresse IP sélectionnée dans l'un des sous-réseaux Private Service Connect.

Ces sous-réseaux ne peuvent pas être utilisés pour des ressources telles que des instances de VM ou des règles de transfert. Les sous-réseaux ne sont utilisés que pour fournir les adresses IP de SNAT des connexions client entrantes.

Pour en savoir plus sur L4ILB pour GKE Private Service Connect et accéder directement au contenu utilisé pour créer cet atelier, consultez les ressources suivantes.

Configuration de l'environnement au rythme de chacun

  1. Connectez-vous à la console Google Cloud, puis créez un projet ou réutilisez un projet existant. (Si vous ne possédez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.)

96a9c957bc475304.png

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.png

  • Le nom du projet est le nom à afficher pour les participants au projet. Il s'agit d'une chaîne de caractères qui n'est pas utilisée par les API Google, et que vous pouvez modifier à tout moment.
  • L'ID du projet doit être unique sur l'ensemble des projets Google Cloud et doit être immuable (vous ne pouvez pas le modifier une fois que vous l'avez défini). Cloud Console génère automatiquement une chaîne unique dont la composition importe peu, en général. Dans la plupart des ateliers de programmation, vous devrez référencer l'ID du projet (généralement identifié comme PROJECT_ID), donc s'il ne vous convient pas, générez-en un autre au hasard ou définissez le vôtre, puis vérifiez s'il est disponible. Il est ensuite "gelé" une fois le projet créé.
  • La troisième valeur est le numéro de projet, utilisé par certaines API. Pour en savoir plus sur ces trois valeurs, consultez la documentation.
  1. Vous devez ensuite activer la facturation dans Cloud Console afin d'utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour arrêter les ressources afin d'éviter qu'elles ne vous soient facturées après ce tutoriel, suivez les instructions de nettoyage indiquées à la fin de l'atelier. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300$.

Démarrer Cloud Shell

Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.

Depuis la console GCP, cliquez sur l'icône Cloud Shell de la barre d'outils située dans l'angle supérieur droit :

bce75f34b2c53987.png

Le provisionnement et la connexion à l'environnement prennent quelques instants seulement. Une fois l'opération terminée, le résultat devrait ressembler à ceci :

f6ef2b5f13479f3a.png

Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez réaliser toutes les activités de cet atelier dans un simple navigateur.

6. Avant de commencer

L'atelier de programmation nécessite deux projets, mais ce n'est pas une exigence pour le PSC. Notez les références pour la prise en charge d'un ou de plusieurs projets.

Projet unique : mettre à jour le projet pour qu'il soit compatible avec le réseau producteur et consommateur

Dans Cloud Shell, assurez-vous que l'ID de votre projet est configuré.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
prodproject=YOUR-PROJECT-NAME
consumerproject=YOUR-PROJECT-NAME
echo $prodproject
echo $consumerproject

Plusieurs projets : mettre à jour le projet pour prendre en charge le réseau de producteurs

Dans Cloud Shell, assurez-vous que l'ID de votre projet est configuré.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
prodproject=YOUR-PROJECT-NAME
echo $prodproject

Remarque concernant la convention de code couleur :

f251ebb137e37136.png

7. Créer un réseau VPC pour les producteurs

afe738fc869f0d6e.png

Réseau VPC

Depuis Cloud Shell

gcloud compute networks create gke-producer-l4-vpc --project=$prodproject --subnet-mode=custom 

Créer un sous-réseau de cluster GKE

Depuis Cloud Shell

gcloud compute networks subnets create node-subnet1 --project=$prodproject --range=192.168.10.0/24 --network=gke-producer-l4-vpc --region=us-central1 --secondary-range=pod=10.10.10.0/24,service=10.10.20.0/24 --enable-private-ip-google-access

Créer un cluster GKE

Depuis Cloud Shell

gcloud container clusters create gke-psc-l4 \
    --release-channel=rapid \
    --enable-ip-alias \
    --zone=us-central1-a \
    --network gke-producer-l4-vpc \
    --num-nodes 1 \
    --subnetwork node-subnet1 \
    --cluster-secondary-range-name pod \
    --services-secondary-range-name service

Créer un sous-réseau pour Private Service Connect (sous-réseau NAT)

Vous devez créer un ou plusieurs sous-réseaux dédiés à utiliser avec Private Service Connect. Si vous utilisez la console Google Cloud pour publier un service, vous pouvez créer les sous-réseaux pendant cette procédure.

Pour en savoir plus sur les sous-réseaux Private Service Connect, consultez Sous-réseaux Private Service Connect.

Depuis Cloud Shell

gcloud beta compute networks subnets create gke-nat-subnet \
    --project $prodproject \
    --network gke-producer-l4-vpc \
    --region us-central1 \
    --range 100.100.10.0/24 \
    --purpose PRIVATE_SERVICE_CONNECT

8. Déployer une charge de travail et des services

Le fichier manifeste suivant décrit un déploiement qui exécute un exemple d'image de conteneur d'application Web. Enregistrez le fichier manifeste sous le nom my-deployment.yaml à partir de Cloud Shell.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: psc-ilb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: psc-ilb
  template:
    metadata:
      labels:
        app: psc-ilb
    spec:
      containers:
      - name: whereami
        image: gcr.io/google-samples/whereami:v1.2.1
        ports:
          - name: http
            containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 5
          timeoutSeconds: 1

Appliquez le fichier manifeste à votre cluster depuis Cloud Shell.

kubectl apply -f my-deployment.yaml

Créer un service

Le fichier manifeste suivant décrit un service qui crée un équilibreur de charge TCP/UDP interne sur le port TCP 8080. Enregistrez le fichier manifeste sous le nom my-service.yaml à partir de Cloud Shell.

apiVersion: v1
kind: Service
metadata:
  name: gke-l4-psc
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  selector:
    app: psc-ilb
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Appliquez le fichier manifeste à votre cluster depuis Cloud Shell.

kubectl apply -f my-service.yaml

Créer un rattachement de service

Le fichier manifeste suivant décrit un ServiceAttachment qui expose le service que vous avez créé aux clients de service. Enregistrez le fichier manifeste sous le nom my-psc.yaml depuis Cloud Shell.

apiVersion: networking.gke.io/v1beta1
kind: ServiceAttachment
metadata:
 name: emoji-sa
 namespace: default
spec:
 connectionPreference: ACCEPT_AUTOMATIC
 natSubnets:
 - gke-nat-subnet
 proxyProtocol: false
 resourceRef:
   kind: Service
   name: gke-l4-psc

Appliquez le fichier manifeste à votre cluster depuis Cloud Shell.

kubectl apply -f my-psc.yaml

L'ServiceAttachment comporte les champs suivants :

  • connectionPreference : préférence de connexion qui détermine la façon dont les clients se connectent au service. Vous pouvez utiliser l'approbation automatique du projet avec la valeur ACCEPT_AUTOMATIC ou l'approbation explicite du projet avec la valeur ACCEPT_MANUAL. Pour en savoir plus, consultez Publier des services à l'aide de Private Service Connect.
  • natSubnets : liste des noms de ressources de sous-réseau à utiliser pour le rattachement de service.
  • proxyProtocol : lorsque cette valeur est définie sur "true", l'adresse IP source du client et l'ID de connexion Private Service Connect sont disponibles dans les requêtes. Ce champ est facultatif et est défini par défaut sur "false" s'il n'est pas fourni.
  • consumerAllowList : liste des projets client autorisés à se connecter au ServiceAttachment. Ce champ ne peut être utilisé que lorsque connectionPreference est défini sur ACCEPT_MANUAL. Pour en savoir plus sur ce champ et d'autres options, consultez Publier des services à l'aide de Private Service Connect.

Validation du producteur

Afficher les détails du rattachement de service

Vous pouvez afficher les détails d'un ServiceAttachment à l'aide de la commande suivante depuis Cloud Shell :

kubectl describe serviceattachment emoji-sa

Afficher l'équilibreur de charge interne de niveau 4 GKE

Dans la console Cloud, accédez à Services réseau → Équilibrage de charge → Frontends.

Identifiez l'adresse IP de l'interface qui correspond au sous-réseau de nœud 192.168.10.0/24 défini précédemment. Notez que votre adresse IP peut être différente (voir la capture d'écran ci-dessous).

ed7a25ed4774977b.png

Afficher le service publié

Dans la console Cloud, accédez à Services réseau → Private Service Connect → Services publiés.

Identifiez le service avec le réseau utilisé dans l'atelier, gke-producer-l4-vpc, (voir la capture d'écran ci-dessous, bien que vos valeurs "Service" et "Cible" puissent être différentes).

5a00836ee514b918.png

Cliquez sur le nom du service pour accéder à l'écran ci-dessous. Notez les informations sur l'attachement de service renseignées dans les informations de base. Notez également que "Projets associés" est vide, car le consommateur ne s'est pas encore enregistré auprès du service. Les boutons ACCEPTER et REFUSER resteront grisés, car la préférence de connexion est définie sur ACCEPT_AUTOMATICALLY. Vous pouvez modifier cette option à tout moment en la définissant sur ACCEPT_MANUAL dans le fichier YAML du rattachement de service (my-psc.yaml).

497f5f43920018c0.png

e246063a23771273.png

9. Créer un réseau VPC pour les consommateurs

1f3c90f1e139e906.png

Dans la section suivante, le VPC consommateur est configuré dans un projet distinct. La communication entre le réseau du consommateur et celui du producteur s'effectue via le rattachement de service défini dans le réseau du consommateur.

L'atelier de programmation nécessite deux projets, mais ce n'est pas une exigence pour le PSC. Notez les références pour la prise en charge d'un ou de plusieurs projets.

Projet unique : mettre à jour le projet pour qu'il soit compatible avec le réseau producteur et consommateur

Dans Cloud Shell, assurez-vous que l'ID de votre projet est configuré.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
consumerproject=YOUR-PROJECT-NAME
prodproject=YOUR-PROJECT-NAME
echo $prodproject
echo $consumerproject

Plusieurs projets : mettre à jour un projet pour qu'il soit compatible avec un réseau consommateur

Dans Cloud Shell, assurez-vous que l'ID de votre projet est configuré.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
consumerproject=YOUR-PROJECT-NAME
echo $consumerproject

Réseau VPC

Depuis Cloud Shell

gcloud compute networks create vpc-demo-consumer --project=$consumerproject --subnet-mode=custom

Créer un sous-réseau pour PSC

Depuis Cloud Shell

gcloud compute networks subnets create consumer-subnet --project=$consumerproject  --range=10.0.60.0/24 --network=vpc-demo-consumer --region=us-central1

Créer un sous-réseau pour les instances de VM

Depuis Cloud Shell

gcloud compute networks subnets create consumer-subnet-vm --project=$consumerproject  --range=10.0.70.0/24 --network=vpc-demo-consumer --region=us-central1

Créer une adresse IP statique pour accéder au service publié

Depuis Cloud Shell

gcloud compute addresses create vpc-consumer-psc --region=us-central1 --subnet=consumer-subnet --addresses 10.0.60.100

Créer des règles de pare-feu

Pour permettre à IAP de se connecter à vos instances de VM, créez une règle de pare-feu qui :

  • S'applique à toutes les instances de VM auxquelles vous souhaitez être accessible à l'aide d'IAP.
  • Autorise le trafic entrant à partir de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP qu'IAP utilise pour le transfert TCP.

Depuis Cloud Shell

gcloud compute firewall-rules create psclab-iap-consumer --network vpc-demo-consumer --allow tcp:22 --source-ranges=35.235.240.0/20 --enable-logging

Bien que cela ne soit pas obligatoire pour PSC, créez une règle de pare-feu de sortie pour surveiller le trafic PSC des consommateurs vers le rattachement de service des producteurs.

gcloud compute --project=$consumerproject firewall-rules create vpc-consumer-psc --direction=EGRESS --priority=1000 --network=vpc-demo-consumer --action=ALLOW --rules=all --destination-ranges=10.0.60.0/24 --enable-logging

10. Créer l'instance de test du consommateur 1

Depuis Cloud Shell

gcloud compute instances create consumer-instance-1 --zone=us-central1-a --machine-type=e2-micro --private-network-ip=10.0.70.10 --no-address --subnet=consumer-subnet-vm --tags=google1 --image-family=debian-10 --image-project=debian-cloud

11. Créer une instance de test consommateur 2

Depuis Cloud Shell

gcloud compute instances create consumer-instance-2 --zone=us-central1-a --machine-type=e2-micro --private-network-ip=10.0.70.20 --no-address --subnet=consumer-subnet-vm --tags=google2 --image-family=debian-10 --image-project=debian-cloud

12. Créer un rattachement de service

À l'étape précédente, vous avez copié la chaîne d'attachement du service de production dans un endroit sûr. Insérons la valeur stockée dans le champ "target-service-attachment".

7abaccc4e24f1ef7.png

Depuis Cloud Shell

gcloud compute forwarding-rules create vpc-consumer-psc-fr --region=us-central1 --network=vpc-demo-consumer --address=vpc-consumer-psc --target-service-attachment=yoursavedproducerserviceattachment

13. Validation : consommateur

Nous utiliserons les journaux CURL et de pare-feu pour valider la communication entre le consommateur et le producteur.

Dans le projet du consommateur, les adresses IP statiques sont utilisées pour établir la communication avec le producteur. Ce mappage d'adresse IP statique à la règle de transfert du consommateur est validé en exécutant la syntaxe suivante.

1f3c90f1e139e906.png

Dans le shell d'utilisation du cloud des VPC consommateurs, identifiez la règle de transfert et l'adresse IP statique.

gcloud compute forwarding-rules describe vpc-consumer-psc-fr --region us-central1

Dans le résultat ci-dessous, nous utiliserons 10.0.60.100 pour accéder au producteur lors d'une étape ultérieure.

IPAddress: 10.0.60.100
creationTimestamp: '2021-09-30T21:13:54.124-07:00'
id: '3564572805904938477'
kind: compute#forwardingRule
labelFingerprint: 42WmSpB8rSM=
name: vpc-consumer-psc-fr
network: https://www.googleapis.com/compute/v1/projects/deepakmichaelstage/global/networks/vpc-demo-consumer
networkTier: PREMIUM
pscConnectionId: '36583161500548196'
pscConnectionStatus: ACCEPTED

Afficher le service associé

Dans la console cloud, accédez à Services réseau → Private Service Connect → Points de terminaison connectés, puis affichez le point de terminaison que vous venez de créer.

206bc00297aaa260.png

Connectons-nous à consumer-instance-1 et testons l'accès au service publié par le producteur.

Dans Cloud Shell, ouvrez un nouvel onglet en cliquant sur +.

81f3210b29faebd3.png

Dans Cloud Shell, procédez comme suit :

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute ssh --zone "us-central1-a" "consumer-instance-1" --project "$projectname"

Une fois connecté à l'instance consumer-instance-1, exécutez une requête curl sur l'adresse IP de la règle de transfert 10.0.60.100.

Dans Cloud Shell, procédez comme suit :

user@consumer-instance-1:~$ curl 10.0.60.100

Exemple de résultat :

user@consumer-instance-1:~$ curl 10.0.60.100
{
  "cluster_name": "gke-psc-l4",
  "host_header": "10.0.60.100",
  "node_name": "gke-gke-psc-l4-default-pool-f2c6e301-vnlz.c.prodprojectid.internal",
  "pod_name": "psc-ilb-588887dfdb-w7tbr",
  "pod_name_emoji": "🤷",
  "project_id": "prodorijectid",
  "timestamp": "2021-10-01T17:43:37",
  "zone": "us-central1-a"

Connectons-nous à consumer-instance-2 et testons l'accès au service publié par le producteur.

Dans Cloud Shell, ouvrez un nouvel onglet en cliquant sur +.

81f3210b29faebd3.png

Dans Cloud Shell, procédez comme suit :

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute ssh --zone "us-central1-a" "consumer-instance-2" --project "$projectname"

Dans Cloud Shell, procédez comme suit :

user@consumer-instance-2:~$ curl 10.0.60.100

Exemple de résultat :

deepakmichael@consumer-instance-2:~$ curl 10.0.60.100
{
  "cluster_name": "gke-psc-l4",
  "host_header": "10.0.60.100",
  "node_name": "gke-gke-psc-l4-default-pool-f2c6e301-vnlz.c.prodproject.internal",
  "pod_name": "psc-ilb-588887dfdb-4jdql",
  "pod_name_emoji": "🧑🏿",
  "project_id": "prodproject",
  "timestamp": "2021-10-01T17:49:51",
  "zone": "us-central1-a"

14. Journalisation de pare-feu : validation attribuée

À l'aide de l'explorateur de journaux, vérifiez que la règle de pare-feu "vpc-consumner-psc" capture le flux entre l'instance de VM et l'adresse IP statique.

  1. Dans la console Cloud, identifiez la journalisation des opérations → Explorateur de journaux.
  2. Dans le champ "Requête", remplacez l'entrée ci-dessous par yourconsumerproject, puis sélectionnez "Exécuter la requête".

logName:(projects/yourconsumerprojectID/logs/compute.googleapis.com%2Ffirewall) AND jsonPayload.rule_details.reference:("network:vpc-demo-consumer/firewall:vpc-consumer-psc")

  1. Les résultats de la requête fournissent les informations suivantes par capture d'écran :

23e427b3060473.png

  1. Développez le journal (jsonPayload → Connection) et identifiez le résultat fourni ci-dessous. Notez que dest_ip : 10.0.60.100 est l'adresse IP TCP statique utilisée pour accéder au service Producer, et que src_ip : 10.0.70.10 ou 10.0.70.20 sont les adresses IP des instances de VM. La disposition est autorisée.

2669743fd1f1cb0d.png

15. Validation : producteur

afe738fc869f0d6e.png

Dans le projet "Producers", vérifiez que le rattachement de service est correctement connecté. Accédez à Services réseau → Private Service Connect → Services publiés.

89ded87a63888f60.png

Cliquez sur le service pour afficher le projet client connecté et son état, comme illustré ci-dessous.

15966d47423ebc5f.png

16. Restreindre l'accès à un service publié

1f3c90f1e139e906.png

Jusqu'à présent, nous avons confirmé que les deux instances avaient accès aux services publiés. Créons une règle de pare-feu de sortie pour refuser l'accès de consumer-instance-2 au service publié.

Par défaut, GCP autorise tout le trafic sortant, mais refuse tout le trafic entrant. Dans les étapes suivantes, nous allons créer une règle de pare-feu basée sur un tag réseau "google2" défini précédemment et utilisé lors de la création de consumer-instance-2 pour refuser l'accès au service publié.

7fa2cda1dfec33a.png

Ouvrez un nouvel onglet Cloud Shell en cliquant sur le bouton + et exécutez la règle de pare-feu suivante dans Cloud Shell.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute --project=$projectname firewall-rules create psc-endpoint-deny-egress --direction=EGRESS --priority=999 --network=vpc-demo-consumer --action=DENY --rules=all --destination-ranges=10.0.60.100/32 --target-tags=google2 --enable-logging

Testons maintenant si consumer-instance-2 peut accéder au service publié. Si votre session a expiré, vous devrez ouvrir une nouvelle session Cloud Shell+ et vous connecter à la VM comme indiqué ci-dessous.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute ssh --zone "us-central1-a" "consumer-instance-2" --project "$projectname"

Dans Cloud Shell, procédez comme suit :

user@consumer-instance-2:~$ curl 10.0.60.100

Exemple de résultat :

user@consumer-instance-2:~$ curl 10.0.60.100
curl: (7) Failed to connect to 10.0.60.100 port 80: Connection timed out

Journalisation du pare-feu : validation refusée

À l'aide de l'explorateur de journaux, vérifiez que la règle de pare-feu "psc-endpoint-deny-egress" capture le flux entre l'instance de VM et l'adresse IP statique.

  1. Dans la console Cloud, identifiez la journalisation des opérations → Explorateur de journaux.
  2. Dans le champ "Requête", remplacez l'entrée ci-dessous par votre projet consommateur, puis sélectionnez "Exécuter la requête".

logName:(projects/yourconsumerprojectID/logs/compute.googleapis.com%2Ffirewall) AND jsonPayload.rule_details.reference:("network:vpc-demo-consumer/firewall:psc-endpoint-deny-egress")

  1. Les résultats de la requête fournissent les informations suivantes par capture d'écran :

83b4fc7348ac93cd.png

  1. Développez le journal et identifiez la sortie fournie ci-dessous. Notez que dest_ip : 10.0.60.100 correspond à l'adresse IP TCP statique et que src_ip : 10.0.70.10 ou 10.0.70.20 correspond à l'adresse IP de l'instance de VM. La disposition est refusée.

a344f75f67590655.png

17. Étapes de nettoyage

Procédure de nettoyage du réseau de producteurs

afe738fc869f0d6e.png

Supprimer les composants de l'atelier à partir d'un seul terminal Cloud Shell dans le projet "Producer"

gcloud container clusters delete gke-psc-l4 --region us-central1-a --quiet

gcloud compute networks subnets delete gke-nat-subnet --region=us-central1 --quiet

gcloud compute networks subnets delete node-subnet1 --region=us-central1 --quiet

gcloud compute networks delete gke-producer-l4-vpc --quiet

1f3c90f1e139e906.png

Procédure de nettoyage du réseau consommateur

Supprimer les composants de l'atelier à partir d'un seul terminal Cloud Shell dans le projet Consumer

gcloud compute instances delete consumer-instance-1 --zone=us-central1-a --quiet

gcloud compute instances delete consumer-instance-2 --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete vpc-consumer-psc-fr --region=us-central1 --quiet

gcloud compute addresses delete vpc-consumer-psc --region=us-central1 --quiet

gcloud compute firewall-rules delete psclab-iap-consumer --quiet

gcloud compute networks subnets delete consumer-subnet --region=us-central1 --quiet

gcloud compute networks subnets delete consumer-subnet-vm --region=us-central1 --quiet

gcloud compute firewall-rules delete vpc-consumer-psc --quiet

gcloud compute firewall-rules delete psc-endpoint-deny-egress --quiet

gcloud compute networks delete vpc-demo-consumer --quiet

18. Félicitations !

Bravo ! Vous avez terminé cet atelier de programmation.

Points abordés

  • Avantages de Private Service Connect
  • Concepts clés pour les clients de services
  • Concepts clés pour les producteurs de services
  • Créer un environnement de production
  • Exposer le service (environnement du producteur) via un rattachement de service
  • Créer un environnement consommateur
  • Créer une règle de transfert dans le réseau consommateur
  • Valider l'accès des consommateurs
  • Activer le contrôle des accès aux règles
  • Utilisation d'une règle de pare-feu de sortie pour bloquer l'accès à une règle de transfert de consommateur