Laboratorio práctico — PCNE Google Cloud Professional Cloud Network Engineer

Descripción general

Requisitos previos

Pasos

1. 1.Proveedor, servicios del proyecto, nomenclatura

   Habilita las APIs de Compute, DNS y Logging.

   Copiar

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       google = { source = "hashicorp/google", version = "~> 6.0" }
     }
   }
   
   provider "google" {
     project = "your-project-id" # REPLACE
     region  = "us-central1"
   }
   
   locals {
     labels = {
       project    = "certlabpro-pcne"
       managed_by = "terraform"
     }
   }
   
   resource "google_project_service" "compute" {
     service            = "compute.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "dns" {
     service            = "dns.googleapis.com"
     disable_on_destroy = false
   }
   
   resource "google_project_service" "logging" {
     service            = "logging.googleapis.com"
     disable_on_destroy = false
   }

2. 2.Habilita el modo de proyecto host de VPC compartida + crea una subred regional

   Aprovisiona:

   • VPC
   • Shared VPC

   Shared VPC es el patrón de red multiproyecto canónico de PCNE: un proyecto host posee la VPC, múltiples proyectos de servicio la consumen a través de adjuntos. Las cargas de trabajo en los proyectos de servicio obtienen IPs de las subredes de la VPC host sin que el proyecto host posea los recursos de la capa de carga de trabajo. El examen PCNE evalúa esta separación host vs servicio como el patrón de escala fundamental.

   Habilitamos el modo de proyecto host en el proyecto actual (google_compute_shared_vpc_host_project), luego creamos una subred /20 con Acceso privado a Google habilitado (permite que las VMs sin IPs externas lleguen a *.googleapis.com) y VPC Flow Logs activados.

   Copiar

   data "google_project" "current" {}
   
   resource "google_compute_shared_vpc_host_project" "host" {
     project = data.google_project.current.project_id
   
     depends_on = [google_project_service.compute]
   }
   
   resource "google_compute_network" "main" {
     name                    = "certlabpro-pcne-vpc"
     auto_create_subnetworks = false
     routing_mode            = "REGIONAL"
   
     depends_on = [google_project_service.compute]
   }
   
   resource "google_compute_subnetwork" "main" {
     name                     = "certlabpro-pcne-subnet"
     ip_cidr_range            = "10.10.0.0/20"
     region                   = "us-central1"
     network                  = google_compute_network.main.id
     private_ip_google_access = true
   
     log_config {
       aggregation_interval = "INTERVAL_5_SEC"
       flow_sampling        = 0.5
       metadata             = "INCLUDE_ALL_METADATA"
     }
   }

3. 3.Agrega Cloud Router + Cloud NAT para salida solo saliente

   Aprovisiona:

   • Cloud NAT
   • Cloud Router

   Cloud NAT proporciona a las subredes acceso saliente a internet sin IPs externas por VM, el patrón de salida privado por defecto canónico de PCNE. La forma: un Cloud Router es la primitiva del plano de control BGP (utilizada por NAT, VPN, Interconnect); un Cloud NAT se adjunta a él y proporciona el plano de datos.

   Habilitamos NAT con asignación de IP NAT AUTO_ONLY (Google elige las direcciones; las implementaciones de producción se fijan a IPs reservadas específicas para las listas de permitidos del firewall ascendente). El registro solo se activa en caso de errores; el modo de registro completo genera un volumen sustancial de Cloud Logging.

   Copiar

   resource "google_compute_router" "nat_router" {
     name    = "certlabpro-pcne-router"
     region  = "us-central1"
     network = google_compute_network.main.id
   }
   
   resource "google_compute_router_nat" "nat" {
     name                               = "certlabpro-pcne-nat"
     router                             = google_compute_router.nat_router.name
     region                             = "us-central1"
     nat_ip_allocate_option             = "AUTO_ONLY"
     source_subnetwork_ip_ranges_to_nat = "LIST_OF_SUBNETWORKS"
   
     subnetwork {
       name                    = google_compute_subnetwork.main.id
       source_ip_ranges_to_nat = ["ALL_IP_RANGES"]
     }
   
     log_config {
       enable = true
       filter = "ERRORS_ONLY"
     }
   }

4. 4.Agrega dos reglas de firewall (interna + IAP SSH)

   Aprovisiona:

   • VPC

   Postura de firewall recomendada por PCNE: denegar el tráfico de entrada por defecto (el predeterminado de GCP), permitir solo lo necesario. Agregamos una regla de permiso interno (cualquier TCP/UDP/ICMP entre VMs en la subred) + permiso IAP SSH (TCP/22 desde el rango de la puerta de enlace IAP de Google, para que las VMs sin IPs públicas sigan siendo accesibles por SSH a través de gcloud compute ssh --tunnel-through-iap).

   Este es el mismo patrón de dos reglas que el laboratorio ACE. PCNE lo profundiza con políticas de firewall en el ámbito de la organización/carpeta (firewalls jerárquicos que se componen con reglas a nivel de proyecto; fuera del alcance aquí).

   Copiar

   resource "google_compute_firewall" "allow_internal" {
     name      = "certlabpro-pcne-allow-internal"
     network   = google_compute_network.main.name
     direction = "INGRESS"
   
     source_ranges = ["10.10.0.0/20"]
   
     allow {
       protocol = "tcp"
     }
     allow {
       protocol = "udp"
     }
     allow {
       protocol = "icmp"
     }
   }
   
   resource "google_compute_firewall" "allow_iap_ssh" {
     name      = "certlabpro-pcne-allow-iap-ssh"
     network   = google_compute_network.main.name
     direction = "INGRESS"
   
     source_ranges = ["35.235.240.0/20"]
   
     allow {
       protocol = "tcp"
       ports    = ["22"]
     }
   }

5. 5.Crea una zona privada de Cloud DNS para resolución interna de nombres

   Aprovisiona:

   • Cloud DNS

   Patrón canónico de PCNE: los nombres de host internos se resuelven a través de una zona privada de Cloud DNS adjunta a la VPC. Las VMs en la VPC ven los registros de esta zona; las VMs externas no. Caso de uso: nombres de host estables y legibles para servicios (api.internal.acme.com, db.internal.acme.com) que se resuelven a la IP privada de la VM.

   Creamos la zona internal.acme.com + un registro A de ejemplo. Las implementaciones de producción a menudo combinan esto con el reenvío de DNS de Cloud DNS para configuraciones híbridas (las consultas DNS locales se reenvían a la zona de la nube y viceversa a través de políticas de servidor entrantes). Con cinco bloques implementados (proveedor+APIs, Shared VPC + subred + registros de flujo, Cloud NAT, firewalls, zona privada de Cloud DNS), el sustrato de PCNE está completo.

   Copiar

   resource "google_dns_managed_zone" "internal" {
     name        = "certlabpro-pcne-internal"
     dns_name    = "internal.acme.com."
     description = "PCNE lab private DNS zone"
     visibility  = "private"
   
     private_visibility_config {
       networks {
         network_url = google_compute_network.main.id
       }
     }
   
     labels = local.labels
   
     depends_on = [google_project_service.dns]
   }
   
   resource "google_dns_record_set" "api_example" {
     managed_zone = google_dns_managed_zone.internal.name
     name         = "api.${google_dns_managed_zone.internal.dns_name}"
     type         = "A"
     ttl          = 300
     rrdatas      = ["10.10.0.10"]
   }

Limpieza