Acceso privado a servicios en redes superpuestas en Google Cloud

gcloud compute instance-templates create nginx-service-instance-template \
--machine-type=e2-medium \
--network-interface=network=default,no-address \
--metadata=startup-script=\ \#\!\ /bin/bash


Crea un managed instance group en Project 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
Una vez creado, el managed instance group lanza una instancia en la zona de destino.
Conéctate por SSH a la instancia y verifica el estado del servicio nginx.




Crea una instancia de prueba de conectividad en Project 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

Las redes de Project A y Project B no tienen conectividad interna entre sí, por lo que la instancia de Project A no puede acceder al servicio que corre en Project B.
Tampoco se permite VPC peering, debido a la superposición de rangos en la red predeterminada.
Configura el balanceador de carga interno
Private Service Connect requiere un balanceador de carga interno para exponer el servicio mediante un service attachment. Para esta configuración crearemos un balanceador de carga TCP interno en Project B.

Crea un nuevo health check HTTP regional para verificar la conectividad HTTP a las VMs por el puerto 80.

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

Crea el backend service para el tráfico 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

Agrega el instance group del servicio nginx al backend service.

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

Crea una forwarding rule para el backend service.

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

Configura una regla de firewall que permita los health checks del balanceador de carga.

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


Publica los servicios en el proyecto productor
Publica el servicio en Project B, el proyecto productor, para que los consumidores en otras redes VPC puedan conectarse y acceder al servicio de forma privada y segura.

Reserva una subred para Private Service Connect. El rango de esta subred no debe superponerse con la red predeterminada.

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

Publica el servicio nginx hacia Project A con aprobación explícita del proyecto.

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
Puedes controlar la lista de consumidores que pueden acceder a los servicios publicados, ya sea con aprobación automática o manual. Consulta Publicar servicios con Private Service Connect.

Configura una regla de firewall que permita a Private Service Connect acceder a las instancias de destino.

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


Configura el endpoint en el proyecto consumidor
Un endpoint en el proyecto consumidor se conecta a los servicios de la red VPC del productor mediante una forwarding rule de Private Service Connect.
Cuando creas un endpoint, este se registra automáticamente en Service Directory, usando el namespace que elijas o el predeterminado, goog-psc-default.
Para que el endpoint esté disponible desde más de una región, activa el global access. El global access se encuentra en Preview.

Reserva una dirección IP interna para asignarla al endpoint.

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

Crea una forwarding rule para conectar el endpoint con el service attachment de Project 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


Prueba la conectividad desde el proyecto consumidor
Los componentes de Private Service Connect ya están configurados en Project A y Project B. Usa la IP del endpoint en Project A para acceder al servicio nginx de Project B.
La prueba confirma que las instancias en redes superpuestas pueden comunicarse de forma privada a través del endpoint de Private Service Connect.

Este ejemplo muestra cómo usar Private Service Connect para publicar y consumir servicios de forma segura en redes superpuestas.
El tráfico se mantiene íntegramente dentro de Google Cloud y ofrece un acceso orientado a servicios entre consumidores y productores, con control granular sobre cómo se accede a cada servicio.
Conoce más sobre Private Service Connect en la página del producto.
\n'yum\ install\ epel-release


Crea un managed instance group en Project B.

Una vez creado, el managed instance group lanza una instancia en la zona de destino.
Conéctate por SSH a la instancia y verifica el estado del servicio nginx.




Crea una instancia de prueba de conectividad en Project A.


Las redes de Project A y Project B no tienen conectividad interna entre sí, por lo que la instancia de Project A no puede acceder al servicio que corre en Project B.
Tampoco se permite VPC peering, debido a la superposición de rangos en la red predeterminada.
Configura el balanceador de carga interno
Private Service Connect requiere un balanceador de carga interno para exponer el servicio mediante un service attachment. Para esta configuración crearemos un balanceador de carga TCP interno en Project B.

Crea un nuevo health check HTTP regional para verificar la conectividad HTTP a las VMs por el puerto 80.


Crea el backend service para el tráfico HTTP.


Agrega el instance group del servicio nginx al backend service.


Crea una forwarding rule para el backend service.


Configura una regla de firewall que permita los health checks del balanceador de carga.



Publica los servicios en el proyecto productor
Publica el servicio en Project B, el proyecto productor, para que los consumidores en otras redes VPC puedan conectarse y acceder al servicio de forma privada y segura.

Reserva una subred para Private Service Connect. El rango de esta subred no debe superponerse con la red predeterminada.


Publica el servicio nginx hacia Project A con aprobación explícita del proyecto.

Puedes controlar la lista de consumidores que pueden acceder a los servicios publicados, ya sea con aprobación automática o manual. Consulta Publicar servicios con Private Service Connect.

Configura una regla de firewall que permita a Private Service Connect acceder a las instancias de destino.



Configura el endpoint en el proyecto consumidor
Un endpoint en el proyecto consumidor se conecta a los servicios de la red VPC del productor mediante una forwarding rule de Private Service Connect.
Cuando creas un endpoint, este se registra automáticamente en Service Directory, usando el namespace que elijas o el predeterminado, goog-psc-default.
Para que el endpoint esté disponible desde más de una región, activa el global access. El global access se encuentra en Preview.

Reserva una dirección IP interna para asignarla al endpoint.


Crea una forwarding rule para conectar el endpoint con el service attachment de Project B.



Prueba la conectividad desde el proyecto consumidor
Los componentes de Private Service Connect ya están configurados en Project A y Project B. Usa la IP del endpoint en Project A para acceder al servicio nginx de Project B.
La prueba confirma que las instancias en redes superpuestas pueden comunicarse de forma privada a través del endpoint de Private Service Connect.

Este ejemplo muestra cómo usar Private Service Connect para publicar y consumir servicios de forma segura en redes superpuestas.
El tráfico se mantiene íntegramente dentro de Google Cloud y ofrece un acceso orientado a servicios entre consumidores y productores, con control granular sobre cómo se accede a cada servicio.
Conoce más sobre Private Service Connect en la página del producto.
\n'yum\ -y\ install\ nginx


Crea un managed instance group en Project B.

Una vez creado, el managed instance group lanza una instancia en la zona de destino.
Conéctate por SSH a la instancia y verifica el estado del servicio nginx.




Crea una instancia de prueba de conectividad en Project A.


Las redes de Project A y Project B no tienen conectividad interna entre sí, por lo que la instancia de Project A no puede acceder al servicio que corre en Project B.
Tampoco se permite VPC peering, debido a la superposición de rangos en la red predeterminada.
Configura el balanceador de carga interno
Private Service Connect requiere un balanceador de carga interno para exponer el servicio mediante un service attachment. Para esta configuración crearemos un balanceador de carga TCP interno en Project B.

Crea un nuevo health check HTTP regional para verificar la conectividad HTTP a las VMs por el puerto 80.


Crea el backend service para el tráfico HTTP.


Agrega el instance group del servicio nginx al backend service.


Crea una forwarding rule para el backend service.


Configura una regla de firewall que permita los health checks del balanceador de carga.



Publica los servicios en el proyecto productor
Publica el servicio en Project B, el proyecto productor, para que los consumidores en otras redes VPC puedan conectarse y acceder al servicio de forma privada y segura.

Reserva una subred para Private Service Connect. El rango de esta subred no debe superponerse con la red predeterminada.


Publica el servicio nginx hacia Project A con aprobación explícita del proyecto.

Puedes controlar la lista de consumidores que pueden acceder a los servicios publicados, ya sea con aprobación automática o manual. Consulta Publicar servicios con Private Service Connect.

Configura una regla de firewall que permita a Private Service Connect acceder a las instancias de destino.



Configura el endpoint en el proyecto consumidor
Un endpoint en el proyecto consumidor se conecta a los servicios de la red VPC del productor mediante una forwarding rule de Private Service Connect.
Cuando creas un endpoint, este se registra automáticamente en Service Directory, usando el namespace que elijas o el predeterminado, goog-psc-default.
Para que el endpoint esté disponible desde más de una región, activa el global access. El global access se encuentra en Preview.

Reserva una dirección IP interna para asignarla al endpoint.


Crea una forwarding rule para conectar el endpoint con el service attachment de Project B.



Prueba la conectividad desde el proyecto consumidor
Los componentes de Private Service Connect ya están configurados en Project A y Project B. Usa la IP del endpoint en Project A para acceder al servicio nginx de Project B.
La prueba confirma que las instancias en redes superpuestas pueden comunicarse de forma privada a través del endpoint de Private Service Connect.

Este ejemplo muestra cómo usar Private Service Connect para publicar y consumir servicios de forma segura en redes superpuestas.
El tráfico se mantiene íntegramente dentro de Google Cloud y ofrece un acceso orientado a servicios entre consumidores y productores, con control granular sobre cómo se accede a cada servicio.
Conoce más sobre Private Service Connect en la página del producto.
\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