מעבדה מעשית — ACE Google Cloud Associate Cloud Engineer

סקירה כללית

דרישות קדם

שלבים

1. 1.ספק, שירותי פרויקט, שמות

   אפשר את ממשקי ה-API של Compute Engine, IAM ו-Cloud Logging. בחינת ACE בודקת דפוס זה של הפעלת API לכל משאב שוב ושוב.

   העתק

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

2. 2.חתוך VPC מותאם אישית + תת-רשת אזורית

   משאבים:

   • VPC
   • Compute Engine

   רשתות GCP הן גלובליות — VPC יחיד משתרע על כל האזורים, ותתי-רשתות הן פרימיטיבים אזוריים שנחצבו ממנו. זוהי צורת שאלה חוזרת בבחינת ACE: ל-AWS יש VPCs אזוריים; ל-Azure יש VNets אזוריים; ל-GCP יש VPC גלובלי עם תתי-רשתות אזוריות.

   אנו משביתים את auto_create_subnetworks (VPC במצב מותאם אישית, ברירת המחדל המומלצת על ידי ACE) ויוצרים תת-רשת /24 יחידה ב-us-central1 עם Private Google Access מופעל, כך שמכונות וירטואליות ללא כתובות IP חיצוניות עדיין יוכלו להגיע לממשקי ה-API של GCP.

   העתק

   resource "google_compute_network" "main" {
     name                    = "certlabpro-ace-vpc"
     auto_create_subnetworks = false
     routing_mode            = "REGIONAL"
   
     depends_on = [google_project_service.compute]
   }
   
   resource "google_compute_subnetwork" "main" {
     name                     = "certlabpro-ace-subnet"
     ip_cidr_range            = "10.10.1.0/24"
     region                   = "us-central1"
     network                  = google_compute_network.main.id
     private_ip_google_access = true
   }

3. 3.הוסף שני כללי חומת אש (פנימי + IAP SSH)

   משאבים:

   • VPC

   כללי חומת האש של GCP הם בתחום ה-VPC (לא לכל תת-רשת) ויש להם כיוון מפורש: ingress (ברירת מחדל) או egress. ingress ברירת המחדל הוא deny-all; egress ברירת המחדל הוא allow-all. בחינת ACE בודקת את הקבוע הזה של כיוון + מניעה כברירת מחדל ללא הרף.

   אנו מוסיפים:

   1. אישור פנימי — TCP/UDP/ICMP בין מכונות וירטואליות בתת-הרשת 10.10.1.0/24.
   2. אישור IAP SSH — TCP/22 מטווח שער ה-IAP של גוגל (35.235.240.0/20) כך שתוכל לבצע SSH מבלי לחשוף את המכונה הווירטואלית לאינטרנט.

   כלל ה-IAP-SSH הוא הדפוס המומלץ על ידי ACE — הוא דורש roles/iap.tunnelResourceAccessor על המכונה הווירטואלית (הקישור מטופל בשלב 4).

   העתק

   resource "google_compute_firewall" "allow_internal" {
     name      = "certlabpro-ace-allow-internal"
     network   = google_compute_network.main.name
     direction = "INGRESS"
   
     source_ranges = ["10.10.1.0/24"]
   
     allow {
       protocol = "tcp"
     }
     allow {
       protocol = "udp"
     }
     allow {
       protocol = "icmp"
     }
   }
   
   resource "google_compute_firewall" "allow_iap_ssh" {
     name      = "certlabpro-ace-allow-iap-ssh"
     network   = google_compute_network.main.name
     direction = "INGRESS"
   
     source_ranges = ["35.235.240.0/20"] # IAP gateway range
   
     allow {
       protocol = "tcp"
       ports    = ["22"]
     }
   }

4. 4.ספק מכונה וירטואלית של GCE עם חשבון שירות בהרשאות מינימליות

   משאבים:

   • Compute Engine
   • IAM

   מכונות וירטואליות של Compute Engine פועלות עם חשבון שירות מצורף — המקביל ב-GCP לפרופיל מופע של AWS EC2 או זהות מנוהלת של מכונה וירטואלית ב-Azure. דפוס מומלץ על ידי ACE: לעולם אל תשתמשו בחשבון השירות המוגדר כברירת מחדל של Compute (עם הרשאות יתר); תמיד צרו חשבון שירות ייעודי לכל עומס עבודה עם רק תפקידי ה-IAM שהעומס עבודה דורש.

   אנו יוצרים חשבון שירות, מעניקים לו את roles/logging.logWriter + roles/monitoring.metricWriter (המינימום הנדרש עבור ה-Ops Agent לשליחת יומנים/מדדים), ומצרפים אותו למכונה וירטואלית Debian מסוג e2-micro ללא IP חיצוני. כלל חומת האש של IAP-SSH משלב 3 מאפשר לך להגיע אליו דרך מנהרה.

   העתק

   resource "google_service_account" "vm" {
     account_id   = "certlabpro-ace-vm-sa"
     display_name = "ACE lab VM service account"
   }
   
   resource "google_project_iam_member" "vm_log_writer" {
     project = data.google_project.current.project_id
     role    = "roles/logging.logWriter"
     member  = "serviceAccount:${google_service_account.vm.email}"
   }
   
   resource "google_project_iam_member" "vm_metric_writer" {
     project = data.google_project.current.project_id
     role    = "roles/monitoring.metricWriter"
     member  = "serviceAccount:${google_service_account.vm.email}"
   }
   
   data "google_project" "current" {}
   
   resource "google_compute_instance" "vm" {
     name         = "certlabpro-ace-vm"
     machine_type = "e2-micro"
     zone         = "us-central1-a"
   
     boot_disk {
       initialize_params {
         image = "debian-cloud/debian-12"
       }
     }
   
     network_interface {
       subnetwork = google_compute_subnetwork.main.id
       # No access_config block = no external IP. SSH via IAP only.
     }
   
     service_account {
       email  = google_service_account.vm.email
       scopes = ["cloud-platform"] # API scope; IAM does the real gating
     }
   
     labels = local.labels
   }

5. 5.חבר מדד Cloud Logging + מדיניות התרעה

   משאבים:

   • Cloud Logging
   • Cloud Monitoring

   צורת תצפית מומלצת על ידי ACE: מדד מבוסס יומן סופר התאמות של מסנן Cloud Logging, ולאחר מכן מדיניות התרעה של Cloud Monitoring מופעלת כאשר המדד חוצה סף. אנו עוקבים אחר שורות יומן severity >= ERROR מכל מכונה וירטואלית של GCE בפרויקט זה, סופרים אותן לדקה, ומתריעים כאשר יותר מ-5 מתרחשות בחלון של 5 דקות.

   ערוץ ההתראה נשאר מרומז — מדיניות התרעות זקוקה למערך notification_channels, אך הערוץ עצמו (דוא"ל, Slack, PagerDuty) מוגדר בדרך כלל פעם אחת לכל פרויקט במסוף. בחינת ACE בודקת את משולש ה-מדד-יומן ← מדיניות התרעה ← ערוץ התראה הזה כפרימיטיב התצפית הסטנדרטי.

   העתק

   resource "google_logging_metric" "vm_errors" {
     name   = "certlabpro_ace_vm_errors"
     filter = "resource.type=\"gce_instance\" AND severity >= ERROR"
   
     metric_descriptor {
       metric_kind = "DELTA"
       value_type  = "INT64"
     }
   
     depends_on = [google_project_service.logging]
   }
   
   resource "google_monitoring_alert_policy" "vm_error_burst" {
     display_name = "ACE lab — VM error burst"
     combiner     = "OR"
   
     conditions {
       display_name = "More than 5 ERROR lines per 5 minutes"
   
       condition_threshold {
         filter          = "metric.type=\"logging.googleapis.com/user/${google_logging_metric.vm_errors.name}\" AND resource.type=\"gce_instance\""
         duration        = "300s"
         comparison      = "COMPARISON_GT"
         threshold_value = 5
   
         aggregations {
           alignment_period   = "60s"
           per_series_aligner = "ALIGN_DELTA"
         }
       }
     }
   
     # notification_channels = [] # add channels via the console or as a separate TF resource
   
     depends_on = [google_project_service.monitoring]
   }

ניקוי משאבים