Praxislabor — PCNE Google Cloud Professional Cloud Network Engineer

Übersicht

Voraussetzungen

Schritte

1. 1.Provider, Projektdienste, Benennung

   Aktivieren Sie die Compute-, DNS- und Logging-APIs.

   Kopieren

   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.Shared VPC Host-Projekt-Modus aktivieren + ein regionales Subnetz erstellen

   Ressourcen:

   • VPC
   • Shared VPC

   Shared VPC ist das PCNE-kanonische Multi-Projekt-Netzwerkmuster – ein Host-Projekt besitzt die VPC, mehrere Dienstprojekte nutzen sie über Anhänge. Workloads in Dienstprojekten erhalten IPs aus den Subnetzen der Host-VPC, ohne dass das Host-Projekt die Workload-Ressourcen besitzt. Die PCNE-Prüfung testet diese Host- vs. Dienst-Trennung als tragendes Skalierungsmuster.

   Wir aktivieren den Host-Projekt-Modus für das aktuelle Projekt (google_compute_shared_vpc_host_project) und erstellen dann ein /20-Subnetz mit aktiviertem Private Google Access (ermöglicht VMs ohne externe IPs, *.googleapis.com zu erreichen) und aktivierten VPC Flow Logs.

   Kopieren

   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.Cloud Router + Cloud NAT für reinen ausgehenden Datenverkehr hinzufügen

   Ressourcen:

   • Cloud NAT
   • Cloud Router

   Cloud NAT ermöglicht Subnetzen ausgehenden Internetzugang ohne externe IPs pro VM – das PCNE-kanonische standardmäßig private Egress-Muster. Die Form: Ein Cloud Router ist das BGP-Steuerungsebenen-Primitiv (verwendet von NAT, VPN, Interconnect); ein Cloud NAT wird daran angehängt und stellt die Datenebene bereit.

   Wir aktivieren NAT mit der IP-Zuweisung AUTO_ONLY (Google wählt die Adressen aus; Produktionsbereitstellungen verwenden spezifische reservierte IPs für Upstream-Firewall-Allowlists). Die Protokollierung erfolgt nur bei Fehlern – der vollständige Protokollmodus erzeugt ein erhebliches Cloud Logging-Volumen.

   Kopieren

   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.Zwei Firewall-Regeln hinzufügen (intern + IAP SSH)

   Ressourcen:

   • VPC

   Die von PCNE empfohlene Firewall-Einstellung: Standardmäßig Ingress verweigern (GCP-Standard), nur das Nötigste zulassen. Wir fügen eine interne 'Alles erlauben'-Regel hinzu (beliebiges TCP / UDP / ICMP zwischen VMs im Subnetz) + eine IAP-SSH-Erlaubnis (TCP/22 aus dem IAP-Gateway-Bereich von Google, sodass VMs ohne öffentliche IPs weiterhin per SSH über gcloud compute ssh --tunnel-through-iap erreichbar sind).

   Dies ist dasselbe Zwei-Regel-Muster wie im ACE-Lab – PCNE vertieft es mit Firewall-Richtlinien auf Organisations- / Ordner-Ebene (hierarchische Firewalls, die mit Regeln auf Projektebene kombiniert werden; hier nicht im Umfang enthalten).

   Kopieren

   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.Eine private Cloud DNS-Zone für die interne Namensauflösung erstellen

   Ressourcen:

   • Cloud DNS

   PCNE-kanonisches Muster: Interne Hostnamen werden über eine an die VPC angehängte Cloud DNS private Zone aufgelöst. VMs in der VPC sehen die Datensätze dieser Zone; VMs außerhalb nicht. Anwendungsfall: stabile, menschenlesbare Hostnamen für Dienste (api.internal.acme.com, db.internal.acme.com), die auf die private IP der VM aufgelöst werden.

   Wir erstellen die Zone internal.acme.com + einen Beispiel-A-Eintrag. Produktionsbereitstellungen kombinieren dies oft mit Cloud DNS DNS-Weiterleitung für Hybrid-Setups (On-Prem-DNS-Abfragen werden an die Cloud-Zone weitergeleitet und umgekehrt über eingehende Server-Richtlinien). Mit den fünf Blöcken (Provider+APIs, Shared VPC + Subnetz + Flow Logs, Cloud NAT, Firewalls, private Cloud DNS-Zone) ist das PCNE-Substrat vollständig.

   Kopieren

   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"]
   }

Bereinigung