Accéder en privé à des services sur des réseaux superposés dans GCP

Configuration cible de Private Service Connect

Le projet B est le projet producteur du service ; un service nginx d'exemple y est déployé sur une instance d'un groupe d'instances managé.

Le projet A est le projet consommateur : il doit accéder en privé au service hébergé dans le projet B. Aucune adresse IP externe n'est attribuée aux instances des deux projets.

• La région GCP retenue pour les ressources est us-west4
• L'API compute.googleapis.com est activée dans les projets A et B
• Cloud NAT permet aux instances privées d'accéder à Internet pour télécharger des paquets

Mettez à jour les variables dans les commandes ci-dessous.

• Créez un modèle d'instance dans le projet B.

gcloud compute instance-templates create nginx-service-instance-template \
--machine-type=e2-medium \
--network-interface=network=default,no-address \
--metadata=startup-script=\ \#\!\ /bin/bash$'\n'yum\ install\ epel-release$'\n'yum\ -y\ install\ nginx$'\n'systemctl\ start\ nginx \
--maintenance-policy=MIGRATE \
--provisioning-model=STANDARD \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--create-disk=auto-delete=yes,boot=yes,device-name=nginx-service-instance-template,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=pd-balanced \
--no-shielded-secure-boot \
--shielded-vtpm \
--shielded-integrity-monitoring \
--reservation-affinity=any \
--project=$PROJECT_B

• Créez un groupe d'instances managé dans le projet B.

gcloud beta compute instance-groups managed create nginx-service-instance-group \
--base-instance-name=nginx-service \
--size=1 \
--template=nginx-service-instance-template \
--zone=us-west4-a \
--list-managed-instances-results=PAGELESS \
--no-force-update-on-repair \
--project=$PROJECT_B

Une fois la création réussie, le groupe d'instances managé lance une instance dans la zone cible.

Connectez-vous à l'instance en SSH et vérifiez l'état du service nginx.

• Créez une instance de test de connectivité dans le projet A.

gcloud compute instances create instance-1 \
    --zone=us-west4-b \
    --machine-type=e2-medium \
    --network-interface=stack-type=IPV4_ONLY,subnet=default,no-address \
    --maintenance-policy=MIGRATE \
    --provisioning-model=STANDARD \
    --scopes=https://www.googleapis.com/auth/cloud-platform \
    --create-disk=auto-delete=yes,boot=yes,device-name=instance-2,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=projects/project-a-385206/zones/us-west4-b/diskTypes/pd-balanced \
    --no-shielded-secure-boot \
    --shielded-vtpm \
    --shielded-integrity-monitoring \
    --labels=ec-src=vm_add-gcloud \
    --reservation-affinity=any \
    --project=$PROJECT_A

Les réseaux des projets A et B ne disposent d'aucune connectivité interne. L'instance du projet A ne peut donc pas atteindre le service exécuté dans le projet B.

Le VPC Peering n'est pas autorisé en raison du chevauchement des plages dans le réseau par défaut.

Un load balancer interne est nécessaire pour que Private Service Connect expose le service via un service attachment. Nous allons créer un load balancer TCP interne pour cette configuration dans le projet B.

• Créez un health check HTTP régional pour tester la connectivité HTTP vers les VM sur le port 80.

gcloud compute health-checks create http nginx-service-health-check \
    --region=us-west4 \
    --port=80 \
    --project=$PROJECT_B

• Créez le service backend pour le trafic HTTP.

gcloud compute backend-services create nginx-service-internal-lb-backend \
    --load-balancing-scheme=internal \
    --protocol=tcp \
    --region=us-west4 \
    --health-checks=nginx-service-health-check \
    --health-checks-region=us-west4 \
    --project=$PROJECT_B

• Ajoutez le groupe d'instances nginx au service backend.

gcloud compute backend-services add-backend nginx-service-internal-lb-backend \
    --region=us-west4 \
    --instance-group=nginx-service-instance-group \
    --instance-group-zone=us-west4-a \
    --project=$PROJECT_B

• Créez une règle de transfert pour le service backend.

gcloud compute forwarding-rules create nginx-service-internal-fr \
    --region=us-west4 \
    --load-balancing-scheme=internal \
    --network=default \
    --subnet=default \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=nginx-service-internal-lb-backend \
    --backend-service-region=us-west4 \
    --project=$PROJECT_B

• Configurez une règle de pare-feu pour autoriser les health checks du load balancer.

gcloud compute firewall-rules create allow-internal-lb-health-check \
--direction=INGRESS \
--priority=1000 \
--network=default \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=35.191.0.0/16,130.211.0.0/22
--project=$PROJECT_B

Publiez le service dans le projet B, c'est-à-dire le projet producteur, afin de permettre aux consommateurs d'autres réseaux VPC de s'y connecter en privé et d'y accéder en toute sécurité.

• Réservez un sous-réseau dédié à Private Service Connect. Sa plage ne doit pas chevaucher celle du réseau par défaut.

gcloud compute networks subnets create private-service-connect \
--network default \
--region us-west4 \
--range 10.0.1.0/24 \
--purpose=PRIVATE_SERVICE_CONNECT \
--project=$PROJECT_B

• Publiez le service nginx vers le projet A avec une approbation explicite du projet.

gcloud compute service-attachments create nginx-service \
    --region=us-west4 \
    --producer-forwarding-rule=nginx-service-internal-fr  \
    --connection-preference=ACCEPT_MANUAL \
    --nat-subnets=private-service-connect \
    --consumer-accept-list=$PROJECT_A=10 \
    --project=$PROJECT_B

Vous pouvez piloter la liste des consommateurs autorisés à accéder aux services publiés via une approbation automatique ou manuelle. Consultez Publier des services à l'aide de Private Service Connect.

• Configurez une règle de pare-feu pour autoriser Private Service Connect à atteindre les instances cibles.

gcloud compute firewall-rules create allow-private-service-connect \
--direction=INGRESS \
--priority=1000 \
--network=default \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=10.0.1.0/24
--project=$PROJECT_B

Dans le projet consommateur, un endpoint se connecte aux services du réseau VPC producteur via une règle de transfert Private Service Connect.

Lorsque vous créez un endpoint, il est automatiquement enregistré auprès de Service Directory, dans un namespace de votre choix ou dans le namespace par défaut goog-psc-default.

Pour rendre l'Endpoint accessible depuis plusieurs régions, activez l'accès global. Cette fonctionnalité est en Preview.

• Réservez une adresse IP interne à attribuer à l'Endpoint.

gcloud compute addresses create private-service-connect-endpoint \
    --region=us-west4 \
    --subnet=default \
    --project=$PROJECT_A

• Créez une règle de transfert pour relier l'Endpoint au service attachment du projet B.

PSC_SERVICE_ATTACHMENT=$(gcloud compute service-attachments describe nginx-service \
   --region=us-west4 \
   --project=$PROJECT_B \
   --format="value(selfLink.scope(projects))")

gcloud compute forwarding-rules create nginx-service \
  --region=us-west4 \
  --network=default \
  --address=private-service-connect-endpoint \
  --target-service-attachment="projects/$PSC_SERVICE_ATTACHMENT" \
  --project=$PROJECT_A

Les composants Private Service Connect sont désormais configurés dans les projets A et B. Utilisez l'IP de l'endpoint dans le projet A pour accéder au service nginx du projet B.

Le test confirme que des instances aux réseaux superposés peuvent communiquer en privé via l'Endpoint Private Service Connect.