Laboratório prático — PCNE Google Cloud Professional Cloud Network Engineer

Visão geral

Pré-requisitos

Passos

1. 1.Provedor, serviços de projeto, nomenclatura

   Habilite as APIs de Compute, DNS e 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.Habilite o modo de projeto host de VPC Compartilhada + crie uma sub-rede regional

   Provisiona:

   • VPC
   • Shared VPC

   VPC Compartilhada é o padrão de rede de múltiplos projetos canônico do PCNE — um projeto host possui a VPC, múltiplos projetos de serviço a consomem via anexos. As cargas de trabalho em projetos de serviço obtêm IPs das sub-redes da VPC do host sem que o projeto host possua os recursos da camada de carga de trabalho. O exame PCNE testa esta separação host vs serviço como o padrão de escala de suporte de carga.

   Nós habilitamos o modo de projeto host no projeto atual (google_compute_shared_vpc_host_project), então criamos uma sub-rede /20 com Acesso Privado do Google habilitado (permite que VMs sem IPs externos alcancem *.googleapis.com) e VPC Flow Logs ativados.

   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.Adicione Cloud Router + Cloud NAT para egresso apenas de saída

   Provisiona:

   • Cloud NAT
   • Cloud Router

   Cloud NAT oferece acesso à internet de saída para sub-redes sem IPs externos por VM — o padrão de egresso privado por padrão canônico do PCNE. O formato: um Cloud Router é a primitiva do plano de controle BGP (usado por NAT, VPN, Interconnect); um Cloud NAT se conecta a ele e fornece o plano de dados.

   Nós habilitamos o NAT com alocação de IP NAT AUTO_ONLY (o Google escolhe os endereços; implantações de produção fixam IPs reservados específicos para listas de permissões de firewall a montante). Registro apenas em erros — o modo de log completo gera um volume substancial 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.Adicione duas regras de firewall (interna + IAP SSH)

   Provisiona:

   • VPC

   Postura de firewall recomendada pelo PCNE: negação padrão de entrada (padrão do GCP), permitindo apenas o que é necessário. Adicionamos permissão interna para tudo (qualquer TCP / UDP / ICMP entre VMs na sub-rede) + permissão IAP SSH (TCP/22 do intervalo de gateway IAP do Google, para que VMs sem IPs públicos ainda sejam acessíveis via SSH usando gcloud compute ssh --tunnel-through-iap).

   Este é o mesmo padrão de duas regras do laboratório ACE — o PCNE o aprofunda com políticas de firewall no escopo da organização/pasta (firewalls hierárquicos que se compõem com regras de nível de projeto; fora do escopo aqui).

   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.Crie uma zona privada do Cloud DNS para resolução de nomes internos

   Provisiona:

   • Cloud DNS

   Padrão canônico do PCNE: nomes de host internos são resolvidos via uma zona privada do Cloud DNS anexada à VPC. VMs na VPC veem os registros desta zona; VMs externas não. Caso de uso: nomes de host estáveis e legíveis para serviços (api.internal.acme.com, db.internal.acme.com) que são resolvidos para o IP privado da VM.

   Criamos a zona internal.acme.com + um registro A de exemplo. Implantações de produção frequentemente combinam isso com o encaminhamento de DNS do Cloud DNS para configurações híbridas (consultas DNS on-prem encaminham para a zona na nuvem, e vice-versa via políticas de servidor de entrada). Com cinco blocos implementados (provedor+APIs, VPC Compartilhada + sub-rede + logs de fluxo, Cloud NAT, firewalls, zona privada do Cloud DNS), o substrato do 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"]
   }

Limpeza