יצירת אזור נחיתה באמצעות Stellar Engine

תהליך הפריסה של אזור הנחיתה מורכב משלבים. במהלך כל שלב, צריך להוסיף משתנים מסוימים לקובץ terraform.tfvars. אחרי שמסיימים שלב, Terraform כותב קובץ STAGE_NAME-tfvar.auto.tfvars.json לקטגוריה של Cloud Storage שנוצרה בשלב הראשוני. בשלבים הבאים נעשה שימוש ב-CLI של Google Cloud כדי להעתיק את הקבצים ואת קובץ הפלאגין שמתממשק עם שירותים חיצוניים שמבצע התחזות לחשבון שירות ספציפי לשלב לתיקיית השלב החדשה.

הפריסה של סביבה חדשה נמשכת כשעה, בהתאם למספר הדיירים.

דרישות מוקדמות

לפני שמפעילים את Stellar Engine, צריך לבצע את המשימות הבאות.

הגדרה של Google Cloud

כדי להגדיר את Google Cloud:

  1. בוחרים Google Cloud ארגון. אם יוצרים ארגון חדש, צריך להיכנס למסוף Google Admin לפחות פעם אחת.

  2. הגדרת כמה אדמינים כדי להטמיע הפרדת תפקידים. בסביבת בדיקה, יכול להיות שלמשתמש אחד יש תפקידי אדמין לכל המשאבים. עם זאת, בסביבת ייצור, נדרשים כמה אדמינים. מידע נוסף זמין במאמר בנושא הגדרת משאבים בארגון.

  3. מפעילים אימות דו-שלבי לכל החשבונות עם הרשאות מיוחדות.

  4. השבתה של Cloud Shell אין תמיכה ב-Cloud Shell בסביבות IL4 או IL5, ואדמין ב-Google Workspace צריך להשבית אותו.

  5. אם אין לכם פרויקט, צרו פרויקט bootstrap.

    יצירת פרויקט

  6. בפרויקט האתחול, מבצעים את המשימות הבאות:

    1. מפעילים את החיוב. הוראות מפורטות זמינות במאמר אימות סטטוס החיוב של הפרויקטים.

    2. מפעילים את Cloud Monitoring API.

      תפקידים שנדרשים להפעלת ממשקי API

      כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

      להפעלת ה-API

  7. מוודאים שחשבון המשתמש שלכם הוא סופר-אדמין.

  8. אם לארגון אין תוכנית לסיווג נתונים, צריך ליצור אחת.

הקצאת תפקידים

מקצים את התפקידים הבאים של ניהול זהויות והרשאות גישה לחשבון המשתמש שמבצע את הפריסה של Stellar Engine.

  1. צריך לוודא שיש לכם בארגון את התפקיד או התפקידים הבאים: Access Transparency Admin, Assured Workloads Administrator, Billing Account Administrator, Logging Admin, Organization Administrator, Organization Policy Admin, Organization Role Administrator, Owner, Project Creator, Service Account Admin, Service Account Token Creator, Tag Admin

    בדיקת התפקידים

    1. נכנסים לדף IAM במסוף Google Cloud .

      כניסה לדף IAM
    2. בוחרים את הארגון.

    3. בעמודה Principal, מחפשים את כל השורות שמזהות אתכם או קבוצה שאתם נכללים בה. כדי לברר באילו קבוצות אתם נכללים, פנו לאדמין.

    4. בודקים את העמודה Role בכל השורות שבהן מצוין או מופיע השם שלכם, כדי לראות אם רשימת התפקידים כוללת את התפקידים הנדרשים.

    מתן התפקידים

    1. נכנסים לדף IAM במסוף Google Cloud .

      כניסה לדף IAM
    2. בוחרים את הארגון.
    3. לוחצים על Grant access.

    4. בשדה New principals, מזינים את מזהה המשתמש. ‫ בדרך כלל מזהה המשתמש הוא כתובת האימייל של חשבון Google.

      ‫
    5. לוחצים על Select a role ומחפשים את התפקיד.
    6. כדי לתת עוד תפקידים, לוחצים על Add another role ומוסיפים אותם.
    7. לוחצים על Save.

אם אתם מתחילים עם ארגון חדש, אתם יכולים להריץ את הסקריפט הבא שנמצא בתיקייה fast/stages-aw/0-bootstrap כדי להקצות את התפקידים:

./setIAM.sh EMAIL_ADDRESS ORGANIZATION_ID

מחליפים את מה שכתוב בשדות הבאים:

  • ‫EMAIL_ADDRESS: כתובת האימייל של חשבון המשתמש.
  • ‫ORGANIZATION_ID: מזהה הארגון.

הסקריפט הזה מוסיף את כל התפקידים חוץ מ-Billing Account Administrator וסופר-אדמין.

הוספת קבוצות והגדרת שירותים

  1. מוסיפים את הקבוצות הבאות, כמו שמתואר בשלב 2. משתמשים וקבוצות:

    • gcp-billing-admins@DOMAIN
    • gcp-developers@DOMAIN
    • gcp-devops@DOMAIN
    • gcp-hybrid-connectivity-admins@DOMAIN
    • gcp-logging-monitoring-admins@DOMAIN
    • gcp-logging-monitoring-viewers@DOMAIN
    • gcp-organization-admins@DOMAIN
    • gcp-vpc-network-admins@DOMAIN
    • gcp-security-admins@DOMAIN

    מעבר לשלב 2

    מחליפים את DOMAIN ב-FQDN.

    אם מתקבלת בקשה, מדלגים על השלב של ספק הזהויות.

    יכול להיות ש-Google תשנה את שמות ברירת המחדל של הקבוצות. אם הקבוצה לא מופיעה במדריך ההגדרה, אפשר ליצור אותה באופן ידני.

  2. מפעילים את ממשקי Assured Workloads,‏ BigQuery,‏ חיוב ב-Cloud,‏ Cloud Logging,‏ Cloud KMS,‏ IAM,‏ Pub/Sub,‏ מנהל המשאבים,‏ Service Account Credentials,‏ Service Usage ו-שירות מדיניות הארגון APIs.

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    הפעלת ממשקי ה-API

    3. אפשר גם להשתמש בסקריפט fast/stages-aw/0-bootstrap/enableServices.sh כדי להפעיל את השירותים.

  3. הפעלת Access Transparency.

  4. אם המכסה שלכם היא פחות מ-13 פרויקטים, אתם יכולים להיכנס אל Google Cloud Platform/API Project: Request Billing Quota Increase ולבקש מכסה של 13 פרויקטים. מידע נוסף מופיע במאמר בנושא איך רואים ומנהלים את המכסות.

הגדרת הסביבה המקומית

כדי להגדיר את הסביבה המקומית:

  1. משכפלים את מאגר GitHub של Stellar Engine.
  2. מתקינים את Google Cloud SDK.
  3. מעדכנים את Terraform המקומי לגרסה 1.8.1 ואילך.
  4. מתקינים את הקובץ הבינארי jq.

  5. מאמתים ומגדירים את פרויקט האתחול כפרויקט הפעיל:

    gcloud auth login
gcloud config set project BOOTSTRAP_PROJECT_ID
gcloud auth application-default login

שינוי מודולים

ברוב המקרים, אפשר להשתמש במאגר בלי לבצע שינויים. אם צריך לשנות מודול, מעתיקים את המודול כולו ומשתמשים במוסכמת השמות <module-se> כדי למנוע התנגשויות במיזוג כשמורידים עדכונים תקופתיים ממאגר המאגדים של Cloud Foundation.

הפעלת שלב 0: אתחול

בשלב 0, החלקים הקיימים של הרשת מותאמים למצב Terraform. בשלב 0 נוצרים חשבונות השירות והפרויקטים הראשוניים של IaC bootstrap. שלב 0 מיועד למעבר מפרויקט כלשהו שהמשתמש התחיל איתו לפרויקט ליבה חדש ולהעברת מצב Terraform.

  1. שינוי הספרייה ל-fast/stages-aw/0-bootstrap.

  2. מעתיקים את הקובץ terraform.tfvars.sample:

    cp terraform.tfvars.sample terraform.tfvars

  3. מעתיקים את הקובץ providers.tf.tmp לקובץ 0-bootstrap-providers.tf:

    cp providers.tf.tmp 0-bootstrap-providers.tf

  4. מעדכנים את הפרטים ב-fast/stages-aw/0-bootstrap/terraform.tfvars:

    billing_account = {
id = "BILLING_ACCOUNT_ID"
}
regions = {
primary = "REGION"
}
organization = {
domain = "DOMAIN"
id = "ORGANIZATION_ID"
customer_id = "CUSTOMER_ID"
}
outputs_location = "~/fast-config"
prefix = "PREFIX"
log_sinks = {
audit-logs = {
filter = "logName:\"/logs/cloudaudit.googleapis.com%2Factivity\" OR logName:\"/logs/cloudaudit.googleapis.com%2Fsystem_event\" OR protoPayload.metadata.@type=\"type.googleapis.com/google.cloud.audit.TransparencyLog\""
type = "logging"
}
vpc-sc = {
filter = "protoPayload.metadata.@type=\"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata\""
type = "logging"
}
workspace-audit-logs = {
filter = "logName:\"/logs/cloudaudit.googleapis.com%2Fdata_access\" and protoPayload.serviceName:\"login.googleapis.com\""
type = "logging"
}
empty-audit-logs = {
filter = ""
type = "logging"
}
}
org_policies_config = {
  constraints = {
    "ALLOWED_POLICY_MEMBER_DOMAINS" = []
    }
  }
fast_features = {
envs = true
}
assured_workloads = {
regime = "COMPLIANCE_REGIME"
location = "LOCATION"
}
bootstrap_project = "BOOTSTRAP_PROJECT_ID"
alert_email = "ALERT_EMAIL"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫BILLING_ACCOUNT_ID: החשבון לחיוב שישמש לפריסת הסביבות. כדי לראות את פרטי החשבון לחיוב, אפשר להיכנס ל Google Cloud מסוף.

      לדף החיוב

    • ‫REGION: האזור הראשי לפריסת משאבים. ערך ברירת המחדל הוא us-east4 עבור IL5 ו-FedRAMP.

      כדי להוסיף אזור משני לפריסת משאבים, מוסיפים את secondary=secondary.

    • ‫DOMAIN: שם הדומיין המוגדר במלואו (FQDN). כדי להציג את ה-FQDN, מריצים את הפקודה gcloud organizations list.

    • ‫ORGANIZATION: מזהה הארגון שלGoogle Cloud הארגון. כדי להציג את מזהה הארגון, מריצים את הפקודה gcloud organizations list.

    • ‫CUSTOMER_ID: מזהה הלקוח בספרייה של Google Workspace. כדי להציג את המזהה, מריצים את הפקודה gcloud organizations list.

    • ‫PREFIX: הקידומת שתוסף לשמות של פרויקטים ומשאבים שנפרסים. שם הפרויקט צריך להיות ייחודי באופן גלובלי, והקידומת צריכה לכלול עד שישה תווים. שגיאה 409 מתרחשת אם שם הפרויקט לא ייחודי.

    • ‫ALLOWED_POLICY_MEMBER_DOMAINS: אם נדרש, מעדכנים עם מזהי לקוחות נוספים. מידע נוסף מופיע במאמר בנושא הגבלת זהויות באמצעות שיתוף עם הגבלת דומיין.

    • ‫COMPLIANCE_REGIME: המשטר של התאימות לסביבה הזו, אחד מהערכים IL4, IL5, FEDRAMP_HIGH ו-COMPLIANCE_REGIME_UNSPECIFIED. אם לא רוצים להשתמש ב-Assured Workloads, צריך להגדיר את הערך הזה ל-COMPLIANCE_REGIME_UNSPECIFIED.

    • ‫LOCATION: האזור בארה"ב שבו רוצים לפרוס משאבים. אין תמיכה באזורים כפולים כמו NAM9 או ביבשות.

    • ‫BOOTSTRAP_PROJECT_ID: מזהה פרויקט האתחול שיצרתם בשלב הגדרה Google Cloud.

    • ‫ALERT_EMAIL: כתובת האימייל שאליה יישלחו התראות על רישום ביומן.

  5. מריצים את terraform init.

  6. מריצים את terraform apply:

    terraform apply -var bootstrap_user=$(gcloud config list --format
 'value(core.account)')

  7. מקלידים yes כשמוצגת בקשה.

  8. עוברים לפרויקט החדש:

    gcloud config set project PREFIX-prod-iac-core-0

  9. מעתיקים את קובץ ספקי Terraform המקומי החדש:

    gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/providers/0-bootstrap-providers.tf ./

  10. מעבירים את המצב ממקומי למרוחק:

    terraform init --migrate-state

  11. מקלידים yes כשמוצגת בקשה.

  12. מריצים את ./import.sh.

  13. מריצים את terraform apply שוב. מקלידים yes כשמוצגת בקשה.

הפעלת שלב 1: ניהול משאבים

בשלב 1 נוצרות התיקיות, הפרויקטים וחשבונות השירות השונים ברמת הארגון, שמשמשים בשלבים הבאים. כדי ליצור את הסביבה, צריך לעדכן את הקובץ terraform.tfvars ב-fast/stages-aw/1-resman כך שיכלול משתנה tenants. כל דייר (לדוגמה, סוכנות פדרלית ספציפית או קבוצת פיתוח פנימית) מקבל גבול ייעודי ומבודד משלו להרצת עומסי העבודה שלו. כל דייר מקבל בירושה את אמצעי הבקרה המרכזיים לאבטחה, את היקף הרשת, את אמצעי הבקרה למדיניות ואת יעד היומן של ביקורת הגישה שנוצרו בשלב 0 ובשלב 2.

  1. אם אתם משתמשים בחשבון חיצוני לחיוב, תוכלו להיעזר במאמר הגדרת חיוב כשמשתמשים בחשבונות חיצוניים לחיוב.

  2. שינוי הספרייה ל-fast/stages-aw/1-resman.

  3. מעתיקים את הקובץ terraform.tfvars.sample:

    cp terraform.tfvars.sample terraform.tfvars

  4. מעדכנים את terraform.tfvars באופן הבא:

    tenants = {
ten-1 = {
  admin_principal = "group:gcp-devops@DOMAIN"
  descriptive_name = "TENANT_ONE_NAME"
  locations = {
    gcs = "REGION"
    kms = "REGION"
    }
  },
ten-2 = {
  admin_principal = "group:gcp-devops@DOMAIN"
  descriptive_name = "TENANT_TWO_NAME"
  locations = {
    gcs = "REGION"
    kms = "REGION"
    }
  }
}
fast_features = {
envs = true
}
envs_folders = {
Prod = {
  admin = "gcp-organization-admins@DOMAIN"
},
Int = {
  admin = "gcp-organization-admins@DOMAIN"
},
Test = {
  admin = "gcp-organization-admins@DOMAIN"
}
}

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫DOMAIN: שם הדומיין הראשי שמוגדר במלואו (FQDN). כדי להציג את ה-FQDN, מריצים את הפקודה gcloud organizations list.

    • ‫TENANT_ONE_NAME: השם של הפרויקט הראשון של הדייר שמוגדר. אפשר להשתמש בשישה תווים לכל היותר.

    • ‫REGION: האזור הראשי לפריסת משאבים. ערך ברירת המחדל הוא us-east4 עבור IL5 ו-FedRAMP.

    • ‫TENANT_TWO_NAME: השם של פרויקט הדייר השני שפריסתו מתבצעת. אפשר להשתמש בשישה תווים לכל היותר.

    מוסיפים כמה הגדרות של דיירים שרוצים.

  5. מעתיקים את הקבצים tfvars מ-Cloud Storage:

    gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/providers/1-resman-providers.tf ./ &&
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-globals.auto.tfvars.json ./ &&
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./

  6. מריצים את terraform init.

  7. מריצים את terraform apply. מקלידים yes כשמוצגת בקשה.

הפעלת שלב 2: יצירת רשת

שלב 2 כולל שתי אפשרויות רשת: אחת ל-FedRAMP High ואחת ל-IL4 או IL5.

הגדרת רשתות ל-FedRAMP High

  1. אם אתם משתמשים בחשבון חיצוני לחיוב, תוכלו להיעזר במאמר הגדרת חיוב כשמשתמשים בחשבונות חיצוניים לחיוב.

  2. שינוי הספרייה ל-fast/stages-aw/2-networking-a-fedramp-high.

  3. מעתיקים את קובצי הספק ואת קובצי tfvars הגלובליים מהקטגוריות של Cloud Storage:

    gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/providers/2-networking-providers.tf ./ && \
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-globals.auto.tfvars.json ./ && \
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./ && \
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./

  4. מעתיקים את הקובץ terraform.tfvars.sample:

    cp terraform.tfvars.sample terraform.tfvars

  5. בקובץ terraform.tfvars, מעדכנים את רשתות המשנה המותאמות אישית, רשתות המשנה של ה-proxy, כללי חומת האש, ה-CIDR עם השם והכללים של מדיניות התגובה של DNS.

  6. מריצים את terraform init.

  7. מריצים את terraform apply. מקלידים yes כשמוצגת בקשה.

הגדרת רשתות בהתאם ל-IL4 או ל-IL5

בשלב הזה פורסים צמד חומות אש מהדור הבא (NGFW) מסוג Palo Alto VM-Series בחשבון הרשת. ה-NGFW משתמשים בתמונת פריסה של Bring Your Own License (BYOL) ודורשים להשתמש במסוף Palo Alto כדי להעלות קוד מכונה ולרשום אותם. הוראות נוספות מופיעות בקובץ README בתיקיית השלב 2-networking-b-il5-ngfw.

  1. אם אתם משתמשים בחשבון חיצוני לחיוב, תוכלו להיעזר במאמר הגדרת חיוב כשמשתמשים בחשבונות חיצוניים לחיוב.

  2. שינוי הספרייה ל-fast/stages-aw/2-networking-b-il5-ngfw.

  3. מעתיקים את קובצי הספק ואת קובצי tfvars הגלובליים מהקטגוריות של Cloud Storage:

    gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/providers/2-networking-providers.tf ./ && \
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-globals.auto.tfvars.json ./ && \
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./ && \
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./

  4. מעתיקים את הקובץ terraform.tfvars.sample:

    cp terraform.tfvars.sample terraform.tfvars

  5. בקובץ terraform.tfvars, מעדכנים את רשתות המשנה בהתאמה אישית (כולל mgmt), רשתות המשנה של ה-proxy, כללי חומת האש, CIDR עם שם וכללי מדיניות של תגובות DNS.

  6. מריצים את terraform init.

  7. מריצים את terraform apply. מקלידים yes כשמוצגת בקשה.

    אם מוצגת שגיאה לגבי חשבון שירות או Cloud Key Management Service שלא קיימים, במסוף לוחצים על הגדרות בחשבון האחסון PREFIX-net-vdss-host. חשבון השירות נוצר.

הפעלת שלב 3: אבטחה וביקורת של הגדרת החשבון

בשלב 3 מגדירים את פרויקטי האבטחה והביקורת. פרויקט האבטחה (prod-sec-core-0) מכיל את Cloud KMS ויכול להכיל את Secret Manager. ב-IL5,‏ CMEK מופעל כברירת מחדל ב-Compute Engine,‏ Google Kubernetes Engine‏ (GKE),‏ Cloud Storage ו-Cloud SQL. האילוצים הבאים של מדיניות הארגון נאכפים:

  • gcp.restrictNonCmekServices:
    • denied_values: "compute.googleapis.com"
    • denied_values: "container.googleapis.com"
    • denied_values: "storage.googleapis.com"
    • denied_values: "sqladmin.googleapis.com"
  • ‫gcp.restrictCmekCryptoKeyProjects: ‫gcp.restrictCmekCryptoKeyProjects כולל רשימה של פרויקטים שאפשר להשתמש בהם ב-CMEK.

בפרויקט prod-sec-core-0 מוגדרים הפריטים הבאים:

  • לאדמינים מוגבלים ב-Cloud KMS מוקצה תפקיד האדמין המוגבל, כדי שיוכלו להעניק הרשאות פענוח לשירותים אחרים.
  • מוקצים אוספי מפתחות של Cloud KMS במיקומים שונים. המיקומים של מחזיקי המפתחות צריכים להיות זהים למיקומי השירות. לדוגמה, אי אפשר להשתמש במחזיק מפתחות במספר אזורים בקטגוריית אחסון באזור יחיד.

פרויקט הביקורת מכיל מאגר ליומנים ליומני ביקורת.

אדמינים של אבטחה אחראים לפרויקט האבטחה, ומבקרים אחראים לפרויקט הביקורת.

  1. אם אתם משתמשים בחשבון חיצוני לחיוב, תוכלו להיעזר במאמר הגדרת חיוב כשמשתמשים בחשבונות חיצוניים לחיוב.

  2. שינוי הספרייה ל-fast/stages-aw/3-security.

  3. מעתיקים את קובצי ההגדרות מהקטגוריות של Cloud Storage:

    gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/providers/3-security-providers.tf ./ &&
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-globals.auto.tfvars.json ./ &&
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./ &&
gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./

  4. מריצים את terraform init.

  5. מריצים את terraform apply. מקלידים yes כשמוצגת בקשה.

    אם נתקלים בבעיה בחשבונות שירות, מריצים מחדש את הפקודה terraform apply.

  6. מריצים את הפקודה ./sa_lockdown.sh כדי להשבית את חשבונות השירות שבהם השתמשתם במהלך הפריסה.

הגדרת חיוב כשמשתמשים בחשבונות חיוב חיצוניים

אם אתם משתמשים בחשבון לחיוב חיצוני, אתם צריכים להוסיף את התפקיד 'אדמין של חשבון לחיוב' לחשבונות השירות הבאים:

  • ‫PREFIX-prod-resman-0@PREFIX-prod-iac-core-0.iam.gserviceaccount.com: החשבון הזה נוצר בשלב 0.

  • ‫PREFIX-prod-resman-net-0@PREFIX-prod-iac-core-0.iam.gserviceaccount.com: חשבון השירות הזה נוצר בשלב 1.

  • ‫PREFIX-security-0@PREFIX-prod-iac-core-0.iam.gserviceaccount.com: חשבון השירות הזה נוצר בשלב 2.

כדי להוסיף את התפקיד לחשבונות השירות האלה, צריך לפעול לפי השלבים במאמרים גישה לחלונית Permissions בחשבון לחיוב ב-Cloud ועדכון תפקידים וחשבונות ראשיים בחלונית Permissions.

שינוי פרויקטים של דייר

כדי להוסיף או להסיר פרויקטים של דיירים לפריסת Stellar Engine קיימת, פועלים לפי השלבים הבאים.

  1. מאמתים ומגדירים את הפרויקט הפעיל:

    gcloud auth login
gcloud config set project PREFIX-prod-iac-core-0
gcloud auth application-default login

  2. מפעילים את חשבונות השירות לשלבים:

    1. שינוי הספרייה ל-fast/stages-aw/3-security.

    2. מריצים את ./sa_lockdown.sh --enable.

  3. החלת שלב 1:

    1. שינוי הספרייה ל-fast/stages-aw/1-resman.

    2. מעדכנים את הפרטים ב-terraform.tfvars בהתאם לדרישות החדשות.

    3. מריצים את terraform init.

    4. מריצים את terraform apply. מקלידים yes כשמוצגת בקשה.

  4. החלת שלב 2:

    1. עוברים לתיקייה אחת מהתיקיות הבאות ברשת:

    2. מעתיקים את קובץ 1-resman tfvars מקטגוריה של Cloud Storage:

    gcloud storage cp gs://PREFIX-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./

    1. מריצים את terraform init.

    2. מריצים את terraform apply. מקלידים yes כשמוצגת בקשה.

  5. משביתים את חשבונות השירות לשלבים:

    1. שינוי הספרייה ל-fast/stages-aw/3-security.

    2. מריצים את ./sa_lockdown.sh.

פתרון בעיות

בקטע הזה מתוארות כמה שגיאות נפוצות ופתרונות לבעיות האלה.

שגיאה שמונעת שימוש ב-BigQuery בשלב 1

אם מופיעה שגיאה שאי אפשר להשתמש ב-bigquery.googleapis.com ב-Assured Workloads, צריך לבצע את הפעולות הבאות:

  1. במסוף, נכנסים לדף Assured Workloads.

    Assured Workloads

  2. בוחרים את התיקייה ואת תיקיית הרשת, אם רלוונטי.StellarEngine-COMPLIANCE_REGIME

  3. לוחצים על בדיקת עדכונים זמינים.

  4. עוברים אל שירותים מורשים.

  5. לוחצים על Allow services (מתן הרשאה לשירותים) כדי להוסיף את ממשקי ה-API של BigQuery.

  6. אם מוצגת בקשה, לוחצים על כן כדי לאשר את הבחירה.

  7. מחכים כשתי דקות ומריצים מחדש את terraform apply:

    terraform apply -var bootstrap_user=$(gcloud config list --format 'value(core.account)')

  8. מקלידים yes כשמוצגת בקשה.

לפרויקט ה-bootstrap אין יותר גישה לחשבון לחיוב

אם הפרויקט הראשוני מאבד את הגישה לחשבון לחיוב, צריך להפעיל מחדש את החיוב בפרויקט הראשוני.

הפעלת החיוב

שגיאות במפתחות Cloud KMS

אם מתרחשות שגיאות במפתחות במהלך תהליך build, יכול להיות שתצטרכו להפעיל את המפתחות באופן ידני. הוראות מפורטות מופיעות במאמר בנושא הפעלת גרסת מפתח.

אם השגיאות האלה מופיעות, צריך לחכות דקה בערך ולהריץ מחדש את הפקודה terraform apply.

במחשב Windows, יכול להיות שקישורים סמליים לא יפעלו. יכול להיות שתצטרכו להעתיק קבצים ספציפיים באופן ידני, במיוחד את psc.tf ואת log-metric-alerts.tf במהלך שלב 2.

בעיות בחיוב או במכסה

אם נתקלתם בבעיות בחיוב או במכסה, ודאו שהפרויקט של המכסה מוגדר. כדי להגדיר את זה, מריצים את הפקודה הבאה:

gcloud auth application-default set-quota-project PREFIX-prod-iac-core-0

אפשר גם להשתמש בפרויקט אחר.

המאמרים הבאים

  • למידע נוסף על הגדרות אבטחה, אפשר לעיין במאמר תקני האבטחה של Gemini.

  • משלבים פתרון SIEM כמו Google Security Operations כדי לעקוב אחרי המשאבים. מפלחים את ה-SIEM בפרויקט נפרד Google Cloud וב-VPC נפרד מהמקום שבו הוא אוסף נתונים.