יצירת אזור נחיתה באמצעות 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). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

      להפעלת ה-API

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

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

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

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

  1. צריך לוודא שיש לכם בארגון את התפקיד או התפקידים הבאים: Access Transparency Admin, Assured Workloads Administrator, Billing Account Administrator, אדמין של רישום ביומן, Organization Administrator, אדמין של מדיניות הארגון, אדמין של תפקידים בארגון, Owner, Project Creator, אדמין של חשבון שירות, יוצר אסימונים של חשבון שירות, אדמין של תגים

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

    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. אם אחד מממשקי ה-API הבאים לא מופעל, צריך להפעיל אותו: Assured Workloads, ‏ BigQuery, ‏ חיוב ב-Cloud, ‏ Cloud Logging, ‏ Cloud KMS, ‏ IAM, ‏ Pub/Sub, ‏ מנהל המשאבים, ‏ Service Account Credentials, ‏ Service Usage, ‏ שירות מדיניות הארגון.

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

    כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (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 בחשבון הרשת. ה-NGFWs משתמשים בתמונת פריסה של 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.

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

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

הפעלת החיוב

שגיאות במפתחות 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 נפרד מהמקום שבו הוא אוסף נתונים.