Usa Private Service Connect para publicar y consumir servicios con GKE

1. Introducción

Private Service Connect permite que un productor de servicios ofrezca servicios de forma privada a un consumidor de servicios. Private Service Connect ofrece los siguientes beneficios:

Una red de VPC del productor de servicios puede admitir más de un consumidor de servicios.
Cada consumidor se conecta a una dirección IP interna que ellos mismos definen. Private Service Connect realiza la traducción de direcciones de red (NAT) para enrutar la solicitud al productor de servicios.

Figura 2: Private Service Connect usa extremos y adjuntos de servicio para permitir que los consumidores de servicios envíen tráfico desde la red de VPC del consumidor hacia servicios en la red de VPC del productor de servicios (haz clic para agrandar).

Qué aprenderás

Beneficios de Private Service Connect
Conceptos clave para los consumidores de servicios
Conceptos clave para los productores de servicios
Crea un entorno de producción
Expón el servicio (entorno del productor) a través de un adjunto de servicio
Crea un entorno de consumidor
Crea una regla de reenvío en la red del consumidor
Valida el acceso del consumidor
Habilita el control de acceso a la política
Usa una regla de firewall de salida para bloquear el acceso a una regla de reenvío del consumidor

Requisitos

Conocimiento sobre la implementación de clústeres y servicios de GKE
Conocimiento de los balanceadores de cargas internos
Capacidad de crear VPCs en dos proyectos
Capacidad para crear un clúster de GKE

2. Beneficios de Private Service Connect

Con PSC, obtienes varios beneficios en comparación con el uso del intercambio de tráfico entre VPC:

Mejor control del espacio de IP privada

Como consumidor de servicios, puedes controlar la dirección IP privada que se usa para conectarte al servicio administrado al que deseas acceder.
Como consumidor de servicios, no necesitas preocuparte por reservar rangos de direcciones IP privadas para los servicios de backend que se consumen en tu VPC. Solo debes elegir una dirección IP de tu propia subred para conectarte a los servicios del productor.
Como productor de servicios, puedes optar por implementar un modelo multiusuario, en el que tu VPC contenga servicios que atiendan a varias VPC de consumidor. Los consumidores que tienen rangos de subredes superpuestos ya no son un problema.
Como proveedor de servicios, puedes escalar tu servicio a tantas instancias de VM como sea necesario, sin necesidad de comunicarte con tu consumidor para obtener más direcciones IP.

Mejor seguridad y aislamiento

Como consumidor de servicios, solo tú puedes iniciar la comunicación con el productor de servicios. Esta conectividad unidireccional simplifica drásticamente la configuración del firewall, pero también reduce el riesgo de tráfico no autorizado procedente del productor de servicios.
Como productor de servicios, no necesitas cambiar las reglas del firewall en función de los rangos de subred en la VPC del consumidor. Solo tienes que crear reglas de firewall para el rango de direcciones IP de NAT configurado en tu servicio.

Mejor escalabilidad

PSC permite un diseño altamente escalable, ya que admite miles de consumidores y permite que los productores de servicios ofrezcan servicios multiusuario o de usuario único altamente escalables.
Como consumidor de servicios que usa Private Service Connect, puedes crear recursos según sea necesario en tu VPC. La escala de esto no se ve afectada por la cantidad de recursos de este tipo creados en la VPC del productor.

3. Conceptos clave para los consumidores de servicios

Puedes usar extremos de Private Service Connect para consumir servicios que están fuera de tu red de VPC. Los consumidores de servicios crean extremos de Private Service Connect que se conectan a un servicio de destino.

Extremos

Usas extremos de Private Service Connect para conectarte a un servicio de destino. Los extremos tienen una dirección IP interna en tu red de VPC y se basan en el recurso de regla de reenvío.

Envías tráfico al extremo, que lo reenvía a destinos fuera de tu red de VPC.

Objetivos

Los extremos de Private Service Connect tienen un destino, que es el servicio al que deseas conectarte:

Un paquete de API:
Todas las API: la mayoría de las API de Google
VPC-SC: las API que admiten los Controles del servicio de VPC
Un servicio publicado en otra red de VPC. Tu propia organización o una externa puede administrar este servicio.

Servicio publicado

Para conectar tu extremo con el servicio de un productor de servicios, necesitas el adjunto de servicio del servicio. El URI del adjunto de servicio tiene este formato: projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME

4. Conceptos clave para los productores de servicios

Para que un servicio esté disponible para los consumidores, debes crear una o más subredes dedicadas para usarlas para la traducción de direcciones de red (NAT) de las direcciones IP de los consumidores. Luego, debes crear un adjunto de servicio que haga referencia a esas subredes.

Subredes de Private Service Connect

Para exponer un servicio, el productor del servicio primero crea una o más subredes con el propósito de Private Service Connect.

Cuando se envía una solicitud desde una red de VPC de consumidor, la dirección IP de origen del consumidor se traduce mediante NAT de origen (SNAT) a una dirección IP seleccionada de una de las subredes de Private Service Connect.

Si deseas conservar la información de la dirección IP de conexión del consumidor, consulta Visualiza la información de conexión del consumidor.

Estas subredes no se pueden usar para recursos como instancias de VM o reglas de reenvío. Las subredes se usan solo a fin de proporcionar direcciones IP para la SNAT de las conexiones entrantes de consumidores.

La subred de Private Service Connect debe contener al menos una dirección IP por cada 63 VMs de consumidor, de modo que a cada VM de consumidor se le asignen 1,024 tuplas de origen para la traducción de direcciones de red.

El tamaño mínimo de una subred de Private Service Connect es /24.

Adjuntos de servicio

Los productores de servicios exponen sus servicios a través de un adjunto de servicio.

Para exponer un servicio, un productor de servicios crea un adjunto de servicio que hace referencia a la regla de reenvío del balanceador de cargas del servicio.
Para acceder a un servicio, un consumidor de servicios crea un extremo que hace referencia al adjunto de servicio.

Preferencias de conexión

Cuando creas un servicio, eliges cómo ponerlo a disposición. Existen dos opciones:

Aceptar conexiones de forma automática para todos los proyectos: Cualquier consumidor de servicios puede configurar un extremo y conectarse al servicio de forma automática.
Aceptar conexiones para proyectos seleccionados: Los consumidores de servicios configuran un extremo para conectarse al servicio, y el productor de servicios acepta o rechaza las solicitudes de conexión.

Requisitos y limitaciones

Se aplican las limitaciones para Private Service Connect.
Puedes crear un adjunto de servicio en las versiones 1.21.4-gke.300 y posteriores de GKE.
No puedes usar la misma subred para múltiples parámetros de configuración de adjuntos de servicio.
Debes crear un servicio GKE que use un balanceador de cargas TCP/UDP interno.

5. Entorno de pruebas

La red del consumidor consta de una dirección IP estática que se usa para originar solicitudes al productor de servicios, además del adjunto de servicio de destino que se asigna al adjunto de servicio del productor (servicio publicado).

Ahora, veamos la red de productores. Observa cómo la red de productores no tiene una asignación a la red de consumidores. En cambio, la red de productores contiene un adjunto de servicio (servicio publicado) que el consumidor usa para los servicios. El adjunto de servicio del productor se expone a través de un ILB de L4 de entrada de GKE (servicio publicado) que habilita la comunicación con los Pods de GKE y las aplicaciones asociadas.

La subred NAT se usa cuando se envía una solicitud desde una red de VPC de consumidor, la dirección IP de origen del consumidor se traduce mediante NAT de origen (SNAT) a una dirección IP seleccionada de una de las subredes de Private Service Connect.

Para obtener más información sobre el ILB de L4 para Private Service Connect de GKE y obtener acceso directo al contenido que se usa para hacer referencia a este lab, consulta lo siguiente.

Configuración del entorno de autoaprendizaje

Accede a Google Cloud Console y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.

El Nombre del proyecto es el nombre visible de los participantes de este proyecto. Es una string de caracteres que no se utiliza en las API de Google y se puede actualizar en cualquier momento.
El ID del proyecto debe ser único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar después de configurarlo). Cloud Console genera automáticamente una string única, que, por lo general, no importa cuál sea. En la mayoría de los codelabs, debes hacer referencia al ID del proyecto (suele ser PROJECT_ID). Por lo tanto, si no te gusta, genera otro aleatorio o prueba con uno propio y comprueba si está disponible. Después de crear el proyecto, este ID se “congela” y no se puede cambiar.
Además, hay un tercer valor, el Número de proyecto, que usan algunas API. Obtén más información sobre estos tres valores en la documentación.

A continuación, deberás habilitar la facturación en Cloud Console para usar las API o los recursos de Cloud. Ejecutar este codelab no debería costar mucho, tal vez nada. Si quieres cerrar los recursos para no se te facture más allá de este instructivo, sigue las instrucciones de “limpieza” que se encuentran al final del codelab. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de USD 300.

Inicia Cloud Shell

Si bien Google Cloud y Spanner se pueden operar de manera remota desde tu laptop, en este codelab usarás Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.

En GCP Console, haga clic en el ícono de Cloud Shell en la barra de herramientas superior derecha:

El aprovisionamiento y la conexión al entorno deberían tomar solo unos minutos. Cuando termine el proceso, debería ver algo como lo siguiente:

Esta máquina virtual está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Puedes realizar todo tu trabajo en este lab usando simplemente un navegador.

6. Antes de comenzar

El codelab requiere dos proyectos, aunque no es un requisito para el PSC. Ten en cuenta las referencias para admitir uno o varios proyectos.

Single Project - Update project to support producer and consumer network

En Cloud Shell, asegúrate de que tu ID del proyecto esté configurado.

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

Varios proyectos: Actualiza el proyecto para admitir la red de productores

En Cloud Shell, asegúrate de que tu ID del proyecto esté configurado.

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

Ten en cuenta la siguiente convención de código de color:

7. Crea la red de VPC de productores

Red de VPC

Desde Cloud Shell

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

Crea una subred del clúster de GKE

Desde 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

Crea un clúster de GKE

Desde 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

Crea una subred para Private Service Connect (subred NAT)

Debes crear una o más subredes dedicadas para usarlas con Private Service Connect. Si usas la consola de Google Cloud para publicar un servicio, puedes crear las subredes durante ese procedimiento.

Para obtener información sobre las subredes de Private Service Connect, consulta Subredes de Private Service Connect.

Desde 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. Implementa una carga de trabajo y servicios

En el siguiente manifiesto, se describe una implementación que ejecuta una imagen de contenedor de aplicación web de muestra. Guarda el manifiesto como my-deployment.yaml desde 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

Aplica el manifiesto al clúster desde Cloud Shell

kubectl apply -f my-deployment.yaml

Creación de servicio

En el siguiente manifiesto, se describe un servicio que crea un balanceador de cargas interno de TCP/UDP en el puerto TCP 8080. Guarda el manifiesto como my-service.yaml desde 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

Aplica el manifiesto al clúster desde Cloud Shell

kubectl apply -f my-service.yaml

Crea un ServiceAttachment

En el siguiente manifiesto, se describe un ServiceAttachment que expone el servicio que creaste a los consumidores de servicios. Guarda el manifiesto como my-psc.yaml desde 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

Aplica el manifiesto al clúster desde Cloud Shell

kubectl apply -f my-psc.yaml

El objeto ServiceAttachment tiene los siguientes campos:

connectionPreference: Es la preferencia de conexión que determina cómo los clientes se conectan al servicio. Puedes usar la aprobación automática del proyecto con ACCEPT_AUTOMATIC o la aprobación explícita del proyecto con ACCEPT_MANUAL. Para obtener más información, consulta Publica servicios con Private Service Connect.
natSubnets: Es una lista de nombres de recursos de subred para usar en el adjunto de servicio.
proxyProtocol: Cuando se configura como verdadero, la IP de origen del consumidor y el ID de conexión de Private Service Connect están disponibles en las solicitudes. Este campo es opcional y su valor predeterminado es falso si no se proporciona.
consumerAllowList: Es la lista de proyectos de consumidor que pueden conectarse al objeto ServiceAttachment. Este campo solo se puede usar cuando connectionPreference es ACCEPT_MANUAL. Para obtener más información sobre este campo y otras opciones, consulta Publica servicios con Private Service Connect.

Validación del productor

Cómo ver los detalles del adjunto de servicio

Puedes ver los detalles de un ServiceAttachment con el siguiente comando de Cloud Shell:

kubectl describe serviceattachment emoji-sa

Visualiza el ILB de L4 de GKE

En la consola de Cloud, navega a Servicios de red → Balanceo de cargas → Back-ends.

Identifica la dirección IP del frontend que se alinea con la subred de nodo definida anteriormente 192.168.10.0/24. Ten en cuenta que la captura de pantalla que se muestra a continuación, tu dirección IP puede ser diferente.

Cómo ver el servicio publicado

En la consola de Cloud, navega a Servicios de red → Private Service Connect → Servicios publicados.

Identifica el servicio con la red que se usa en el lab, gke-producer-l4-vpc, (observa la captura de pantalla a continuación, aunque los valores de Service y Target pueden diferir).

Haz clic en el nombre del servicio que te lleva a la siguiente pantalla y observa los detalles del adjunto de servicio que se completaron en la información básica. También observa que “Proyectos conectados” está vacío, ya que el consumidor aún no se registró en el servicio. ACEPTAR y RECHAZAR permanecerán inhabilitados, ya que Preferencia de conexión está configurada como "ACCEPT_AUTOMATICALLY". Esta opción se puede cambiar en cualquier momento a "ACCEPT_MANUAL" modificando el archivo YAML del adjunto de servicio (my-psc.yaml).

9. Crea la red de VPC de los consumidores

En la siguiente sección, se configura la VPC del consumidor en un proyecto independiente. La comunicación entre la red del consumidor y la del productor se logra a través de la vinculación de servicio definida en la red del consumidor.

El codelab requiere dos proyectos, aunque no es un requisito para el PSC. Ten en cuenta las referencias para admitir uno o varios proyectos.

Single Project - Update project to support producer and consumer network

En Cloud Shell, asegúrate de que tu ID del proyecto esté configurado.

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

Varios proyectos: Actualiza el proyecto para admitir una red de consumidor

En Cloud Shell, asegúrate de que tu ID del proyecto esté configurado.

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

Red de VPC

Desde Cloud Shell

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

Crea una subred para el PSC

Desde Cloud Shell

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

Crea una subred para las instancias de VM

Desde 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

Crea una dirección IP estática para acceder al servicio publicado

Desde Cloud Shell

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

Crea reglas de firewall

Para permitir que IAP se conecte a tus instancias de VM, crea una regla de firewall que cumpla con lo siguiente:

Se aplica a todas las instancias de VM a las que deseas acceder mediante IAP.
Permite el tráfico de entrada desde el rango de IP 35.235.240.0/20. Este rango contiene todas las direcciones IP que IAP usa para el reenvío de TCP.

Desde 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

Aunque no es necesario para PSC, crea una regla de firewall de salida para supervisar el tráfico de PSC del consumidor al adjunto de servicio de los productores.

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. Crea la instancia de prueba del consumidor 1

Desde 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. Crea la instancia de prueba del consumidor 2

Desde 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. Crea un adjunto de servicio

En un paso anterior, copiaste la cadena de Producer Service Attachment en un lugar seguro. Ahora, inserta el valor almacenado en el campo "target-service-attachment".

Desde 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. Validación: Consumidor

Usaremos los registros de CURL y de firewall para validar la comunicación entre el consumidor y el productor.

En el proyecto del consumidor, las direcciones IP estáticas se usan para originar la comunicación con el productor. Esta asignación de la dirección IP estática a la regla de reenvío del consumidor se valida con la siguiente sintaxis.

Desde la shell de Cloud de las VPC de consumidor, identifica la regla de reenvío y la IP estática.

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

En el siguiente resultado, usaremos 10.0.60.100 para llegar al productor en un paso posterior.

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

Cómo ver el servicio conectado

En la consola de Cloud, navega a Servicios de red → Private Service Connect → Extremos conectados y visualiza el extremo recién creado.

Accedamos a consumer-instance-1 y probemos el acceso al servicio publicado del productor

En Cloud Shell, haz clic en el signo + para abrir una pestaña nueva.

En Cloud Shell, haz lo siguiente:

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"

Una vez que accedas a la instancia consumer-instance-1, realiza una solicitud curl a la dirección IP de la regla de reenvío 10.0.60.100.

En Cloud Shell, haz lo siguiente:

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

Ejemplo de resultado:

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"

Accedamos a consumer-instance-2 y probemos el acceso al servicio publicado del productor.

En Cloud Shell, haz clic en el signo + para abrir una pestaña nueva.

En Cloud Shell, haz lo siguiente:

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"

En Cloud Shell, haz lo siguiente:

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

Ejemplo de resultado:

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. Registro de firewall: Validación asignada

Usa el Explorador de registros para validar que la regla de firewall "vpc-consumner-psc" capture el flujo entre la instancia de la VM y la IP estática.

En la consola de Cloud, identifica Operations Logging → Explorador de registros
En el campo Consulta, actualiza la entrada a continuación con tuproyectodeconsumidor y selecciona "Ejecutar consulta".

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

Los resultados de la búsqueda proporcionan la siguiente información por captura de pantalla:

Expande el registro (jsonPayload → Connection) y, luego, identifica el resultado que se proporciona a continuación. Toma nota de dest_ip: 10.0.60.100 es la IP TCP ESTÁTICA que se usa para acceder al servicio de Producer, y src_ip: 10.0.70.10 o 10.0.70.20 son las direcciones IP de la instancia de VM. La disposición es Allowed.

15. Validación: Productor

En el proyecto de productores, verifica que el adjunto de servicio se haya conectado correctamente. Navega a Servicios de red → Private Service Connect → Servicios publicados.

Si haces clic en el servicio, se revelarán el proyecto consumidor conectado y el estado, como se ilustra a continuación.

16. Restringe el acceso a un servicio publicado

Hasta ahora, confirmamos que ambas instancias tienen acceso a los servicios publicados. Creemos una regla de firewall de salida para denegar el acceso de consumer-instance-2 al servicio publicado.

De forma predeterminada, GCP permite todo el tráfico de salida, pero rechaza todo el tráfico de entrada. En los siguientes pasos, crearemos una regla de firewall basada en una etiqueta de redes definida previamente, "google2", que se usó cuando se creó consumer-instance-2 para denegar el acceso al servicio publicado.

Haz clic en el signo más (+) para abrir una pestaña nueva de Cloud Shell y ejecuta la siguiente regla de firewall en 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

Ahora, probemos si consumer-instance-2 puede acceder al servicio publicado. Si se agotó el tiempo de espera de tu sesión, deberás abrir una nueva sesión de Cloud Shell y acceder a la VM como se detalla a continuación.

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"

En Cloud Shell, haz lo siguiente:

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

Ejemplo de resultado:

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

Registro de firewall: Validación rechazada

Usa el Explorador de registros para validar que la regla de firewall "psc-endpoint-deny-egress" capture el flujo entre la instancia de VM y la IP estática.

En la consola de Cloud, identifica Operations Logging → Explorador de registros
En el campo Query, actualiza la entrada a continuación con tu consumerproject y selecciona "Run Query".

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

Los resultados de la búsqueda proporcionan la siguiente información por captura de pantalla:

Expande el registro e identifica el resultado que se proporciona a continuación. Ten en cuenta que dest_ip: 10.0.60.100 es la IP TCP estática y src_ip: 10.0.70.10 o 10.0.70.20 son las direcciones IP de las instancias de VM. La disposición es Denied.

17. Pasos para la limpieza

Pasos para limpiar la red del productor

Desde una sola instancia de Cloud Shell en la terminal del proyecto del productor, borra los componentes del lab.

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

Pasos para limpiar la red del consumidor

Desde una sola shell de Cloud en la terminal del proyecto del consumidor, borra los componentes del lab.

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. ¡Felicitaciones!

Felicitaciones por completar el codelab.

Temas abordados

Beneficios de Private Service Connect
Conceptos clave para los consumidores de servicios
Conceptos clave para los productores de servicios
Crea un entorno de producción
Expón el servicio (entorno del productor) a través de un adjunto de servicio
Crea un entorno de consumidor
Crea una regla de reenvío en la red del consumidor
Valida el acceso del consumidor
Habilita el control de acceso a la política
Se usó una regla de firewall de salida para bloquear el acceso a una regla de reenvío del consumidor.