Lab práctico · Semana 4: Redes en Google Cloud (II): conectividad híbrida, multicloud y entre VPC

Private Service Connect para APIs de Google y Shared VPC (guiado)

Qué vas a construir

Este lab tiene dos partes:

• Parte A (en tu proyecto normal): una VM sin IP externa que accede a Cloud Storage primero por Private Google Access y después por un endpoint de Private Service Connect (PSC) para APIs de Google, con una IP interna elegida por ti y nombres DNS privados.
• Parte B (lectura guiada u opcional): montar una Shared VPC con un host project y un service project, con permisos por subred.

flowchart LR
  subgraph VPC["vpc-psc"]
    VM["vm-cliente sin IP externa, subred con PGA"]
    EP["Endpoint PSC pscapis: 10.255.255.10"]
    DNS["Zona privada p.googleapis.com creada automáticamente"]
  end
  VM -->|"storage-pscapis.p.googleapis.com"| DNS
  DNS --> EP
  EP -->|"paquete all-apis"| API["APIs de Google: Cloud Storage"]

Antes de empezar

• Haber hecho el lab-06-vpc-firewall-nat.
• En Cloud Shell:

export PROJECT_ID="tu-proyecto-pca"
export REGION="europe-southwest1"
export ZONE="europe-southwest1-a"
gcloud config set project $PROJECT_ID
gcloud services enable compute.googleapis.com dns.googleapis.com \
  servicedirectory.googleapis.com iap.googleapis.com storage.googleapis.com

PSC para APIs de Google necesita las APIs de Compute Engine, Cloud DNS y Service Directory.

Parte A. Paso 1: red y VM sin IP externa

Creas una subred sin Private Google Access para ver primero el problema.

gcloud compute networks create vpc-psc --subnet-mode=custom
gcloud compute networks subnets create subred-psc \
  --network=vpc-psc --region=$REGION --range=10.30.0.0/24

gcloud compute firewall-rules create vpc-psc-allow-iap --network=vpc-psc \
  --direction=INGRESS --action=ALLOW --rules=tcp:22 --source-ranges=35.235.240.0/20

gcloud compute instances create vm-cliente --zone=$ZONE --machine-type=e2-micro \
  --subnet=subred-psc --no-address --scopes=cloud-platform \
  --image-family=debian-12 --image-project=debian-cloud

gcloud storage buckets create gs://${PROJECT_ID}-lab09 --location=$REGION
echo "hola PSC" > hola.txt && gcloud storage cp hola.txt gs://${PROJECT_ID}-lab09/

La VM usa la cuenta de servicio por defecto de Compute Engine. Si tu proyecto no la tiene o no tiene permisos de lectura en Cloud Storage, crea una cuenta de servicio con roles/storage.objectViewer y pásala con --service-account.

Parte A. Paso 2: comprobar que sin PGA no hay acceso

gcloud compute ssh vm-cliente --zone=$ZONE --tunnel-through-iap \
  --command="timeout 20 gcloud storage cat gs://${PROJECT_ID}-lab09/hola.txt || echo SIN-ACCESO"

Obtendrás SIN-ACCESO: sin IP externa, sin Cloud NAT y sin Private Google Access, la VM no llega a las APIs públicas de Google.

Parte A. Paso 3: activar Private Google Access

gcloud compute networks subnets update subred-psc --region=$REGION \
  --enable-private-ip-google-access

gcloud compute ssh vm-cliente --zone=$ZONE --tunnel-through-iap \
  --command="gcloud storage cat gs://${PROJECT_ID}-lab09/hola.txt"

Ahora ves hola PSC. La VM usa las IP públicas de storage.googleapis.com, pero el tráfico no sale a Internet.

Parte A. Paso 4: crear el endpoint de PSC para APIs de Google

Reservas una IP global interna con propósito PRIVATE_SERVICE_CONNECT (que no esté en ninguna subred de la VPC) y creas una regla de reenvío global que apunta al paquete all-apis. El nombre del endpoint debe tener de 1 a 20 caracteres, solo minúsculas y números, empezando por letra.

Consola: Network services → Private Service Connect → Connected endpoints → Connect endpoint → Target: All Google APIs.

gcloud compute addresses create ip-psc-apis --global \
  --purpose=PRIVATE_SERVICE_CONNECT \
  --addresses=10.255.255.10 --network=vpc-psc

gcloud compute forwarding-rules create pscapis --global \
  --network=vpc-psc --address=ip-psc-apis \
  --target-google-apis-bundle=all-apis

Google Cloud crea automáticamente una zona privada de Cloud DNS p.googleapis.com con nombres del tipo SERVICIO-pscapis.p.googleapis.com que apuntan a 10.255.255.10.

gcloud dns managed-zones list
gcloud compute forwarding-rules describe pscapis --global

Parte A. Paso 5: usar el endpoint

Entra en la VM y comprueba que el nombre del endpoint resuelve a tu IP interna:

gcloud compute ssh vm-cliente --zone=$ZONE --tunnel-through-iap

Dentro de la VM:

getent hosts storage-pscapis.p.googleapis.com

Debe devolver 10.255.255.10. Ahora lee el objeto a través del endpoint con la API JSON de Cloud Storage (sustituye TU_PROYECTO):

TOKEN=$(gcloud auth print-access-token)
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://storage-pscapis.p.googleapis.com/storage/v1/b/TU_PROYECTO-lab09/o/hola.txt?alt=media"

Verás hola PSC. También puedes decirle a gcloud que use el endpoint para Cloud Storage:

gcloud config set api_endpoint_overrides/storage https://storage-pscapis.p.googleapis.com/storage/v1/
gcloud storage cat gs://TU_PROYECTO-lab09/hola.txt
gcloud config unset api_endpoint_overrides/storage
exit

Comprueba que funciona

• Sin PGA: la VM no llega a Cloud Storage.
• Con PGA: llega usando los nombres públicos de las APIs.
• Con el endpoint PSC: storage-pscapis.p.googleapis.com resuelve a tu IP interna 10.255.255.10 y la lectura funciona por ella.

¿Qué aporta PSC frente a PGA? Una IP interna tuya que puedes anunciar a on-premises por Cloud Router o usar desde redes conectadas, control sobre qué paquete de APIs se expone (all-apis o vpc-sc) y la posibilidad de crear varios endpoints.

Limpieza (parte A)

gcloud compute forwarding-rules delete pscapis --global --quiet
gcloud compute addresses delete ip-psc-apis --global --quiet
gcloud compute instances delete vm-cliente --zone=$ZONE --quiet
gcloud compute firewall-rules delete vpc-psc-allow-iap --quiet
gcloud compute networks subnets delete subred-psc --region=$REGION --quiet
gcloud compute networks delete vpc-psc --quiet
gcloud storage rm --recursive gs://${PROJECT_ID}-lab09
rm -f hola.txt

Revisa con gcloud dns managed-zones list que no queda ninguna zona asociada al endpoint. Si quedara alguna creada para vpc-psc, bórrala con gcloud dns managed-zones delete NOMBRE.

Parte B: Shared VPC (lectura guiada u opcional con organización)

Escenario: el equipo central de red gestiona red-host (host project) y el equipo de la tienda despliega en tienda-svc (service project), solo en la subred subred-tienda.

Requisitos: una organización (Cloud Identity Free vale), dos proyectos dentro de ella con facturación y, para ti, el rol Shared VPC Admin (roles/compute.xpnAdmin) en la organización o carpeta (y roles/resourcemanager.projectIamAdmin).

export HOST_PROJECT="red-host-xxxx"
export SVC_PROJECT="tienda-svc-xxxx"
export ORG_ID="123456789012"
export DEV="usuario-tienda@tu-dominio.com"

B.1 Darte el rol de Shared VPC Admin

gcloud organizations add-iam-policy-binding $ORG_ID \
  --member="user:$(gcloud config get-value account)" \
  --role="roles/compute.xpnAdmin"

B.2 Crear la red en el host project

gcloud compute networks create vpc-compartida --project=$HOST_PROJECT --subnet-mode=custom
gcloud compute networks subnets create subred-tienda --project=$HOST_PROJECT \
  --network=vpc-compartida --region=$REGION --range=10.40.0.0/24
gcloud compute networks subnets create subred-pagos --project=$HOST_PROJECT \
  --network=vpc-compartida --region=$REGION --range=10.40.1.0/24

B.3 Habilitar el host project y adjuntar el service project

gcloud compute shared-vpc enable $HOST_PROJECT
gcloud compute shared-vpc associated-projects add $SVC_PROJECT \
  --host-project=$HOST_PROJECT
gcloud compute shared-vpc get-host-project $SVC_PROJECT

B.4 Permisos a nivel de subred (separación de funciones)

Concedes Network User solo sobre subred-tienda, no sobre todo el host project. El equipo de la tienda podrá crear VMs en esa subred, pero no en subred-pagos, ni tocar rutas o firewall.

gcloud compute networks subnets add-iam-policy-binding subred-tienda \
  --project=$HOST_PROJECT --region=$REGION \
  --member="user:$DEV" --role="roles/compute.networkUser"

Si el service project va a usar GKE u otros servicios gestionados, sus agentes de servicio también necesitan roles/compute.networkUser en la subred (consulta la documentación de cada servicio).

B.5 Crear una VM del service project en la subred compartida

La crea el equipo de la tienda desde su proyecto, refiriéndose a la subred del host por su ruta completa:

gcloud compute instances create vm-tienda --project=$SVC_PROJECT \
  --zone=$ZONE --machine-type=e2-micro --no-address \
  --subnet=projects/$HOST_PROJECT/regions/$REGION/subnetworks/subred-tienda \
  --image-family=debian-12 --image-project=debian-cloud

Observa: la VM se factura al service project, pero su IP pertenece a la subred del host y las reglas de firewall las controla el equipo de red en el host project. Si el mismo usuario intenta usar subred-pagos, recibirá un error de permisos.

Limpieza (parte B, si la hiciste)

gcloud compute instances delete vm-tienda --project=$SVC_PROJECT --zone=$ZONE --quiet
gcloud compute shared-vpc associated-projects remove $SVC_PROJECT --host-project=$HOST_PROJECT
gcloud compute shared-vpc disable $HOST_PROJECT
gcloud compute networks subnets delete subred-tienda subred-pagos --project=$HOST_PROJECT --region=$REGION --quiet
gcloud compute networks delete vpc-compartida --project=$HOST_PROJECT --quiet

Preguntas para pensar como arquitecto