Atelier pratique — PCNE Google Cloud Professional Cloud Network Engineer

Présentation

Prérequis

Étapes

1. 1.Fournisseur, services de projet, dénomination

   Activez les API Compute, DNS et Logging.

   Copier

   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.Activer le mode projet hôte Shared VPC + créer un sous-réseau régional

   Déploie :

   • VPC
   • Shared VPC

   Le Shared VPC est le modèle de réseau multi-projets canonique pour le PCNE — un projet hôte possède le VPC, plusieurs projets de service le consomment via des attachements. Les charges de travail des projets de service obtiennent des adresses IP des sous-réseaux du VPC hôte sans que le projet hôte ne possède les ressources de la couche de charge de travail. L'examen PCNE teste cette séparation hôte vs service comme modèle d'échelle porteur de charge.

   Nous activons le mode projet hôte sur le projet actuel (google_compute_shared_vpc_host_project), puis nous créons un sous-réseau /20 avec l'Accès Google Privé activé (permet aux VMs sans IPs externes d'atteindre *.googleapis.com) et les Journaux de flux VPC activés.

   Copier

   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.Ajouter un Cloud Router + Cloud NAT pour la sortie uniquement

   Déploie :

   • Cloud NAT
   • Cloud Router

   Cloud NAT offre aux sous-réseaux un accès Internet sortant sans IPs externes par VM — le modèle de sortie privé par défaut canonique pour le PCNE. La forme : un Cloud Router est la primitive du plan de contrôle BGP (utilisée par NAT, VPN, Interconnect) ; un Cloud NAT s'y attache et fournit le plan de données.

   Nous activons NAT avec l'allocation d'adresses IP NAT AUTO_ONLY (Google choisit les adresses ; les déploiements de production épinglent des IPs réservées spécifiques pour les listes d'autorisation de pare-feu en amont). Journalisation uniquement sur les erreurs — le mode journal complet génère un volume Cloud Logging substantiel.

   Copier

   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.Ajouter deux règles de pare-feu (interne + IAP SSH)

   Déploie :

   • VPC

   Posture de pare-feu recommandée par PCNE : refus par défaut de l'entrée (par défaut de GCP), n'autoriser que ce qui est nécessaire. Nous ajoutons une autorisation interne complète (tout TCP / UDP / ICMP entre VMs dans le sous-réseau) + une autorisation IAP SSH (TCP/22 depuis la plage de passerelles IAP de Google, afin que les VMs sans IPs publiques soient toujours accessibles en SSH via gcloud compute ssh --tunnel-through-iap).

   Il s'agit du même modèle à deux règles que le labo ACE — PCNE l'approfondit avec les règles de pare-feu au niveau de l'organisation / du dossier (pare-feu hiérarchiques qui se combinent avec les règles au niveau du projet ; hors de portée ici).

   Copier

   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.Créer une zone privée Cloud DNS pour la résolution de noms interne

   Déploie :

   • Cloud DNS

   Modèle canonique PCNE : les noms d'hôte internes sont résolus via une zone privée Cloud DNS attachée au VPC. Les VMs du VPC voient les enregistrements de cette zone ; les VMs externes ne les voient pas. Cas d'utilisation : des noms d'hôte stables et lisibles par l'homme pour les services (api.internal.acme.com, db.internal.acme.com) qui se résolvent en l'IP privée de la VM.

   Nous créons la zone internal.acme.com + un enregistrement A d'exemple. Les déploiements en production associent souvent cela au transfert DNS Cloud DNS pour les configurations hybrides (les requêtes DNS sur site sont transférées vers la zone cloud, et vice versa via des politiques de serveur entrant). Avec cinq blocs en place (fournisseur+APIs, Shared VPC + sous-réseau + journaux de flux, Cloud NAT, pare-feu, zone privée Cloud DNS), le substrat PCNE est complet.

   Copier

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

Nettoyage