אילוצים של מדיניות הארגון לגבי Cloud Load Balancing

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

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

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

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

הגבלת סוגים של מאזני עומסים

משתמשים במדיניות הארגון כדי להגביל את הסוגים של Cloud Load Balancing שאפשר ליצור בארגון. מגדירים את האילוץ הבא של מדיניות הארגון:

שם: הגבלת יצירה של מאזני עומסים על סמך סוגים של מאזני עומסים
מזהה: constraints/compute.restrictLoadBalancerCreationForTypes

כשמגדירים את האילוץ compute.restrictLoadBalancerCreationForTypes, צריך לציין רשימת היתרים או רשימת חסימה של סוגי Cloud Load Balancing. רשימת הערכים המותרים או האסורים יכולה לכלול רק ערכים מהרשימה הבאה:

מאזני עומסים של אפליקציות (ALB)
- ‫GLOBAL_EXTERNAL_MANAGED_HTTP_HTTPS למאזן עומסים גלובלי חיצוני של אפליקציות
- ‫EXTERNAL_HTTP_HTTPS למאזן עומסים קלאסי של אפליקציות (ALB)
- ‫GLOBAL_INTERNAL_MANAGED_HTTP_HTTPS למאזן עומסים פנימי של אפליקציות בין אזורים
- ‫EXTERNAL_MANAGED_HTTP_HTTPS למאזן עומסים חיצוני אזורי של אפליקציות (ALB)
- ‫INTERNAL_HTTP_HTTPS למאזן עומסים פנימי אזורי של אפליקציות
מאזני עומסים של רשת בשרת proxy
- ‫GLOBAL_EXTERNAL_MANAGED_TCP_PROXY למאזן עומסי רשת גלובלי חיצוני בשרת proxy עם שרת proxy של TCP
- ‫GLOBAL_EXTERNAL_MANAGED_SSL_PROXY למאזן עומסי רשת גלובלי חיצוני בשרת proxy עם שרת proxy של SSL
- ‫EXTERNAL_TCP_PROXY למאזן עומסי רשת קלאסי בשרת proxy עם שרת TCP Proxy
- ‫EXTERNAL_SSL_PROXY למאזן עומסי רשת קלאסי בשרת proxy עם שרת proxy של SSL
- ‫GLOBAL_INTERNAL_MANAGED_TCP_PROXY למאזן עומסי רשת פנימי לשרת proxy חוצה אזורים עם שרת TCP Proxy
- ‫REGIONAL_EXTERNAL_MANAGED_TCP_PROXY למאזן עומסי רשת אזורי חיצוני בשרת proxy עם TCP proxy
- ‫REGIONAL_INTERNAL_MANAGED_TCP_PROXY למאזן עומסי רשת אזורי פנימי בשרת proxy עם TCP proxy
מאזני עומסי רשת להעברת סיגנל ללא שינוי
- ‫EXTERNAL_NETWORK_TCP_UDP למאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי
- ‫INTERNAL_TCP_UDP למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי

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

הוראות לדוגמה לשימוש באילוץ הזה מופיעות במאמר הגדרת אילוצי רשימה באמצעות מדיניות הארגון.

אחרי שמגדירים את המדיניות, היא נאכפת כשמוסיפים אתGoogle Cloud כללי ההעברה המתאימים. האילוץ לא נאכף על הגדרות קיימות של Cloud Load Balancing.

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

Constraint constraints/compute.restrictLoadBalancerCreationForTypes
violated for projects/PROJECT_NAME. Forwarding Rule projects/PROJECT_NAME/region/REGION/forwardingRules/FORWARDING_RULE_NAME
of type SCHEME is not allowed.

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

הודעות שגיאה ב-GKE

אם אתם משתמשים ב-Google Kubernetes Engine‏ (GKE), ומישהו בארגון שלכם יצר מדיניות ארגונית שמגבילה את הסוגים של איזוני עומסים שאפשר ליצור, תוצג לכם הודעת שגיאה דומה לזו:

Warning  Sync    28s   loadbalancer-controller  Error during sync: error running
load balancer syncing routine: loadbalancer FORWARDING_RULE_NAME
does not exist: googleapi: Error 412:
Constraint constraints/compute.restrictLoadBalancerCreationForTypes violated for
projects/PROJECT_ID. Forwarding Rule
projects/PROJECT_ID/global/forwardingRules/FORWARDING_RULE_NAME
of type LOAD_BALANCER_TYPE is not allowed, conditionNotMet

בהתאם למדיניות, יכול להיות שהיא תגביל את היכולת שלכם ליצור משאבי איזון עומסים חדשים, כמו Services, ‏ Ingresses או Gateways. כדי להבין אילו הגבלות חלות, צריך לפנות לאדמינים של מדיניות הארגון.

כדי לראות את הודעות השגיאה של GKE, מריצים את הפקודות הבאות:

kubectl get events -w

kubectl describe RESOURCE_KIND NAME

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

‫RESOURCE_KIND: סוג מאזן העומסים, ingress או service
‫NAME: השם של מאזן העומסים

השבתת איזון עומסים גלובלי

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

שם: השבתה של איזון עומסים גלובלי
מזהה: constraints/compute.disableGlobalLoadBalancing

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

הוראות לדוגמה לשימוש באילוץ הזה מופיעות במאמר הגדרת אילוצים בוליאניים באמצעות מדיניות הארגון.

הגבלת סוגי הפריסות של העברת פרוטוקולים

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

שם: הגבלת העברת פרוטוקולים על סמך סוג כתובת ה-IP
מזהה: constraints/compute.managed.restrictProtocolForwardingCreationForTypes

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

INTERNAL
EXTERNAL

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

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

הוראות לדוגמה לשימוש באילוץ הזה מופיעות במאמר הגדרת אילוצי רשימה באמצעות מדיניות הארגון.

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

Constraint constraints/compute.managed.restrictProtocolForwardingCreationForTypes
violated for projects/PROJECT_NAME. Forwarding Rule
projects/PROJECT_NAME/region/REGION/forwardingRules/FORWARDING_RULE_NAME
of type SCHEME is not allowed.

אם מגדירים כמה אילוצים של compute.managed.restrictProtocolForwardingCreationForTypes ברמות שונות של משאבים, ואם מגדירים את השדה inheritFromParent לערך true, האילוצים נאכפים באופן היררכי.

אכיפת הגבלות ב-VPC משותף

משתמשים במדיניות הארגון הבאה כדי להגביל את האופן שבו מותר למשתמשים להגדיר פריסות של VPC משותף.

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

האילוץ המנוהל הזה מדור קודם מאפשר להגביל את הפרויקטים המארחים של VPC משותף שאליהם אפשר לצרף משאב.

שם: הגבלת פרויקטים מארחים של VPC משותף
מזהה: constraints/compute.restrictSharedVpcHostProjects

כברירת מחדל, פרויקט יכול להיות משויך לכל פרויקט מארח באותו ארגון, וכך להפוך לפרויקט שירות. כשמגדירים את האילוץ compute.restrictSharedVpcHostProjects, אפשר לציין רשימת היתרים או רשימה שחורה של פרויקטים מארחים בדרכים הבאות:

מציינים פרויקט בפורמט הבא:
- projects/PROJECT_ID
מציינים פרויקט, תיקייה או ארגון. האילוץ חל על כל הפרויקטים שמתחת למשאב שצוין בהיררכיית המשאבים. משתמשים בפורמט הבא:
- under:organizations/ORGANIZATION_ID
- under:folders/FOLDER_ID

הוראות לדוגמה לשימוש באילוץ הזה מופיעות במאמר הגדרת אילוצי רשימה באמצעות מדיניות הארגון.

הגבלת תת-רשתות של VPC משותף

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

שם: הגבלת תת-רשתות של VPC משותף
מזהה: constraints/compute.restrictSharedVpcSubnetworks

כברירת מחדל, משאבים שעומדים בדרישות יכולים להשתמש בכל תת-רשת של VPC משותף. כשמגדירים את האילוץ compute.restrictSharedVpcSubnetworks, מציינים רשימה מוגבלת של רשתות משנה באחת מהדרכים הבאות:

מציינים רשת משנה בפורמט הבא:
- projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME
מציינים פרויקט, תיקייה או ארגון. ההגבלה חלה על כל רשתות המשנה מתחת למשאב שצוין בהיררכיית המשאבים. משתמשים בפורמט הבא:
- under:organizations/ORGANIZATION_ID
- under:folders/FOLDER_ID
- under:projects/PROJECT_ID

הוראות לדוגמה לשימוש באילוץ הזה מופיעות במאמר הגדרת אילוצי רשימה באמצעות מדיניות הארגון.

הגבלת גישה ל-backend buckets ולשירותי backend בין פרויקטים

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

שם: הגבלת קטגוריות של קצה עורפי ושירותים לקצה העורפי בין פרויקטים
מזהה: constraints/compute.restrictCrossProjectServices

כברירת מחדל, מפת URL בפרויקט אחד יכולה להפנות לשירותי קצה עורפי ולמאגרי קצה עורפי תואמים מפרויקטים אחרים באותו ארגון, כל עוד למשתמש שמבצע את הפעולה יש את ההרשאה compute.backendServices.use, compute.regionBackendServices.use או compute.backendBuckets.use.

כדי להגדיר את האילוץ restrictCrossProjectServices, אפשר לציין רשימת היתרים או רשימת חסימה של שירותים עורפיים או של מאגרי מידע עורפיים באחת מהדרכים הבאות:

מציינים שירותי קצה עורפי בפורמט הבא:
- projects/PROJECT_ID/regions/REGION/backendservices/BACKEND_SERVICE_NAME
- projects/PROJECT_ID/global/backendservices/BACKEND_SERVICE_NAME
מציינים קטגוריות בקצה העורפי בפורמט הבא:
- projects/PROJECT_ID/regions/REGION/backendbuckets/BACKEND_BUCKET_NAME
- projects/PROJECT_ID/global/backendbuckets/BACKEND_BUCKET_NAME
מציינים פרויקט, תיקייה או ארגון. האילוץ חל על כל השירותים לקצה העורפי ועל כל הקטגוריות לקצה העורפי שמוגדרים מתחת למשאב שצוין בהיררכיית המשאבים. צריך להשתמש בפורמט הבא:
- under:organizations/ORGANIZATION_ID
- under:folders/FOLDER_ID
- under:projects/PROJECT_ID

אחרי שמגדירים מדיניות ארגון עם האילוץ הזה, האילוץ נכנס לתוקף בפעם הבאה שמשתמשים בפקודה gcloud compute url-maps כדי לצרף שירות לקצה העורפי או קטגוריית קצה עורפי למפת URL. המגבלה לא משפיעה רטרואקטיבית על הפניות הקיימות לשירותי backend או לדלי backend בין פרויקטים.

המגבלה הזו חלה על כל סוגי הפריסות, כולל VPC משותף. כדי למנוע התנגשויות, מומלץ לא להשתמש באילוץ הזה ובאילוץ compute.restrictSharedVpcBackendServices שמתואר בקטע הבא.

הוראות לדוגמה לשימוש באילוץ הזה מופיעות במאמר הגדרת אילוצי רשימה באמצעות מדיניות הארגון.

הגבלת שירותים לקצה עורפי ב-VPC משותף

אתם יכולים להשתמש באילוץ הזה כדי להגביל את שירותי ה-Backend שמיפוי כתובות URL יכול להפנות אליהם בפריסות של VPC משותף שמשתמשות בהפניה לשירותים בין פרויקטים. המגבלה הזו לא חלה על שירותים לקצה העורפי באותו פרויקט כמו מפת URL.

שם: הגבלת שירותים לקצה העורפי של VPC משותף
מזהה: constraints/compute.restrictSharedVpcBackendServices

במקום זאת, מומלץ להשתמש באילוץ compute.restrictCrossProjectServices שמתואר בקטע הקודם. ההגבלה compute.restrictCrossProjectServices חלה על כל סוגי הפריסות, בין אם מדובר ב-VPC משותף או לא, וגם על בקטים של קצה עורפי וגם על שירותים של קצה עורפי.

הגבלת ההסרה של מנעול למניעת מחיקה של פרויקט VPC משותף

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

שם: הגבלת הסרת מנעול למניעת מחיקה של פרויקט VPC משותף
מזהה: constraints/compute.restrictXpnProjectLienRemoval

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

הוראות לדוגמה לשימוש באילוץ הזה מופיעות במאמר הגדרת אילוצים בוליאניים באמצעות מדיניות הארגון.

הגבלת יכולות TLS באמצעות אילוצים בהתאמה אישית

כדי לעמוד בדרישות התאימות ולהגביל יכולות מסוימות של אבטחת שכבת התעבורה (TLS), אתם יכולים ליצור את אילוץ מדיניות הארגון הבא ולהשתמש בו יחד עם אילוצים בהתאמה אישית למשאבי מדיניות SSL:

שם: דרישה של מדיניות SSL
מזהה: constraints/compute.requireSslPolicy

באמצעות האילוץ compute.requireSslPolicy יחד עם אילוצים מותאמים אישית לשדות של מדיניות SSL, תוכלו ליצור הגבלות שמותאמות לפריסות שלכם. לדוגמה, אתם יכולים:

כדי לשפר את האבטחה ולעמוד בדרישות התאימות, כדאי להגביל את השימוש בגרסאות קודמות של TLS (כמו 1.0 ו-1.1) ובסטים של אלגוריתמים להצפנה.
שיפור הביצועים על ידי הפחתת מספר הלחיצות הנדרשות לתיאום ושיפור התאימות של מאזן העומסים ללקוחות.
החלת הגבלה על צומת משאב ספציפי ועל צאצאיו. לדוגמה, אם דוחים את TLS גרסה 1.0 בארגון, היא נדחית גם בכל התיקיות והפרויקטים (צאצאים) שנגזרים מהארגון הזה.

כדי לאכוף מדיניות SSL במאזן עומסים של אפליקציות או במאזן עומסי רשת בשרת proxy, צריך לצרף אותה לשרת ה-proxy של HTTPS או לשרת ה-proxy של SSL.

כדי לעדכן מדיניות SSL קיימת, אפשר לעיין במאמר בנושא ניהול מדיניות SSL.

שימוש בכללים בוליאניים במדיניות הארגון

ההרשאות שנדרשות למשימה הזו

כדי לבצע את המשימה הזו נדרשות ההרשאות הבאות:

תפקיד האדמין של מדיניות הארגון (roles/orgpolicy.policyAdmin). מידע נוסף זמין במאמר בקרת גישה למשאבים ארגוניים באמצעות IAM.

המסוף

כדי להגדיר מדיניות ארגונית מהמסוף, מבצעים את השלבים הבאים:

במסוף Google Cloud , נכנסים לדף מדיניות הארגון.
מעבר אל מדיניות הארגון
בשדה Filter, מחפשים את האילוץ לפי Name או לפי ID.
לוחצים על שם האילוץ.
לוחצים על עריכה כדי לערוך את האילוץ.
בדף עריכה, בוחרים באפשרות התאמה אישית.
בקטע אכיפה, בוחרים אפשרות אכיפה:
- כדי להפעיל את האכיפה של האילוץ הזה, בוחרים באפשרות On (מופעל).
- כדי להשבית את האכיפה של ההגבלה הזו, בוחרים באפשרות Off.
אחרי שמבצעים שינויים, לוחצים על שמירה כדי להחיל את הגדרות ההגבלה.

הוראות מפורטות להתאמה אישית של מדיניות הארגון באמצעות מסוף Google Cloud זמינות במאמר התאמה אישית של המדיניות בנושא אילוצים בוליאניים.

gcloud

כדי להפעיל אכיפה של אילוץ שמשתמש בכללים בוליאניים, משתמשים בפקודה gcloud resource-manager org-policies enable-enforce באופן הבא.

כדי להפעיל הגבלה על הסרת מנעול למניעת מחיקה של פרויקט VPC משותף:

gcloud resource-manager org-policies enable-enforce \
    --organization ORGANIZATION_ID \
    constraints/compute.restrictXpnProjectLienRemoval

כדי להשבית את איזון העומסים הגלובלי:

gcloud resource-manager org-policies enable-enforce \
    --organization ORGANIZATION_ID \
    constraints/compute.disableGlobalLoadBalancing

הוראות מפורטות לעבודה עם כללים בוליאניים ב-gcloud זמינות במאמר שימוש בכללים בוליאניים במדיניות הארגון.

הגדרת כללים של רשימות במדיניות הארגון

ההרשאות שנדרשות למשימה הזו

כדי לבצע את המשימה הזו נדרשות ההרשאות הבאות:

תפקיד האדמין של מדיניות הארגון (roles/orgpolicy.policyAdmin). מידע נוסף זמין במאמר בקרת גישה למשאבים ארגוניים באמצעות IAM.

המסוף

כדי להגדיר מדיניות ארגונית מהמסוף, מבצעים את השלבים הבאים:

במסוף Google Cloud , נכנסים לדף מדיניות הארגון.
מעבר אל מדיניות הארגון
בשדה Filter, מחפשים את האילוץ לפי Name או לפי ID. לדוגמה, כדי להגביל פרויקטים מארחים של VPC משותף, מחפשים את המזהה: constraints/compute.restrictSharedVpcHostProjects.
לוחצים על שם האילוץ.
לוחצים על עריכה כדי לערוך את האילוץ.
כדי ליצור מדיניות בהתאמה אישית, בוחרים באפשרות התאמה אישית ומציינים את רשימת המשאבים המותרים או רשימת המשאבים האסורים. הוראות מפורטות יותר לגבי התאמה אישית של מדיניות הארגון באמצעות Google Cloud המסוף זמינות במאמר התאמה אישית של מדיניות להגבלות על רשימות.
אחרי שמבצעים שינויים, לוחצים על שמירה כדי להחיל את הגדרות ההגבלה.

gcloud

בקטע הזה מופיעות כמה דוגמאות להגדרות שמראות איך ליצור ולהגדיר מדיניות ארגונית עם אילוץ מנוהל מדור קודם באמצעות כללים של רשימות. הוראות מפורטות נוספות על עבודה עם כללים ליצירת רשימות ועם כללי מדיניות ארגונית ב-gcloud זמינות במאמר שימוש בכללים ליצירת רשימות במדיניות ארגונית.

יוצרים את קובץ המדיניות. אפשר להשתמש בדוגמאות הבאות של הגדרות JSON כדי ליצור קובץ מדיניות משלכם בהתאם לדרישות שלכם.

הגבלת סוגי מאזני העומסים

איך מאפשרים רק חלק ממאזני העומסים

{
"constraint": "constraints/compute.restrictLoadBalancerCreationForTypes",
"listPolicy": {
  "allowedValues": [
    "INTERNAL_TCP_UDP",
    "EXTERNAL_NETWORK_TCP_UDP"
  ]
}
}

דחייה של כל מאזני העומסים החיצוניים

{
"constraint": "constraints/compute.restrictLoadBalancerCreationForTypes",
"listPolicy": {
  "deniedValues": [
    "in:EXTERNAL"
  ]
}
}

דחייה של כל מאזני העומסים

{
"constraint": "constraints/compute.restrictLoadBalancerCreationForTypes",
"listPolicy": {
  "allValues": "DENY"
}
}

הגבלת סוגים של העברת פרוטוקולים

דחיית כל העברת פרוטוקולים

{
"name": "RESOURCE_TYPE/RESOURCE_ID/policies/compute.managed.restrictProtocolForwardingCreationForTypes",
"spec": {
  "rules": [
    {
      "enforce": ["true"],
      "parameters": {
        "denyAll": "true"
      }
    }
  ]
}
}

איך מאפשרים העברת פרוטוקול פנימית בלבד

{
"name": "RESOURCE_TYPE/RESOURCE_ID/policies/compute.managed.restrictProtocolForwardingCreationForTypes",
"spec": {
  "rules": [
    {
      "enforce": ["true"],
      "parameters": {
        "allowedSchemes": "EXTERNAL"
      }
    }
  ]
}
}

הגבלת הגדרות של VPC משותף

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

{
"constraint": "constraints/compute.restrictSharedVpcHostProjects",
"listPolicy": {
  "allowedValues": [
    "under:folders/FOLDER_ID",
    "under:projects/PROJECT_ID"
  ]
}
}

הגבלת רשתות משנה ב-VPC משותף

{
"constraint": "constraints/compute.restrictSharedVpcSubnetworks",
"listPolicy": {
  "deniedValues": [
    "under:organizations/ORGANIZATION_ID",
    "projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME"
  ]
}
}

הגבלת שירותי קצה עורפיים של VPC משותף

{
"constraint": "constraints/compute.restrictCrossProjectServices",
"listPolicy": {
  "allowedValues": [
    "under:folders/FOLDER_ID",
    "under:projects/PROJECT_ID",
    "projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME"
  ]
}
}

החלת האילוץ על משאב: ארגון, תיקייה או פרויקט.

בארגונים, מריצים את הפקודה הבאה:
```
gcloud resource-manager org-policies set-policy POLICY_FILE \
    --organization=ORGANIZATION_ID
```
לתיקיות, מריצים את הפקודה הבאה:
```
gcloud resource-manager org-policies set-policy POLICY_FILE \
    --folder=FOLDER_ID
```
לפרויקטים, מריצים את הפקודה הבאה:
```
gcloud resource-manager org-policies set-policy POLICY_FILE \
    --project=PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫POLICY_FILE: הנתיב המלא לקובץ ה-YAML של מדיניות הארגון.
- ‫ORGANIZATION_ID: מזהה הארגון.
- ‫FOLDER_ID: מזהה התיקייה.
- ‫PROJECT_ID: מזהה הפרויקט.

הגדרת מדיניות ארגונית להחלת מדיניות SSL על שרתי proxy של HTTPS ועל שרתי proxy של SSL

ההרשאות שנדרשות למשימה הזו

כדי לבצע את המשימה הזו נדרשות ההרשאות הבאות:

תפקיד האדמין של מדיניות הארגון (roles/orgpolicy.policyAdmin). מידע נוסף זמין במאמר בקרת גישה למשאבים ארגוניים באמצעות IAM.

המסוף

כדי להגדיר מדיניות ארגונית מהמסוף, מבצעים את השלבים הבאים:

במסוף Google Cloud , נכנסים לדף מדיניות הארגון.

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

gcloud

בקטע הזה מופיעות כמה דוגמאות להגדרות שמראות איך ליצור ולהגדיר קובץ מדיניות ארגוני עם האילוץ compute.requireSslPolicy.

יוצרים קובץ מדיניות כדי לאסור שימוש במדיניות SSL.

{
  "constraint": "constraints/compute.requireSslPolicy",
  "listPolicy": {
    "allValues": "DENY"
  }
}

יוצרים קובץ מדיניות כדי להחיל מדיניות SSL על כל שרתי ה-proxy של HTTPS ו-SSL שמוגדרים כיעדים מתחת למשאב שצוין בהיררכיית המשאבים:
```
{
  "constraint": "constraints/compute.requireSslPolicy",
  "listPolicy": {
    "allowedValues": [
      "under:folders/FOLDER_ID",
      "under:projects/PROJECT_ID"
    ]
  }
}
```
החלת האילוץ על שרתי proxy של HTTPS ו-SSL: ארגון, תיקייה או פרויקט.

בארגונים, מריצים את הפקודה הבאה:
```
gcloud resource-manager org-policies set-policy PATH_TO_POLICY_FILE \
    --organization=ORGANIZATION_ID
```
לתיקיות, מריצים את הפקודה הבאה:
```
gcloud resource-manager org-policies set-policy PATH_TO_POLICY_FILE \
    --folder=FOLDER_ID
```
לפרויקטים, מריצים את הפקודה הבאה:
```
gcloud resource-manager org-policies set-policy PATH_TO_POLICY_FILE \
    --project=PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PATH_TO_POLICY_FILE: הנתיב לקובץ המדיניות
- ‫ORGANIZATION_ID: מזהה הארגון
- ‫FOLDER_ID: מזהה התיקייה
- ‫PROJECT_ID: מזהה הפרויקט

כדי לקבל את המדיניות האפקטיבית ולאמת את התנהגות ברירת המחדל של המשאב (ארגון, תיקייה או פרויקט), מריצים את הפקודות הבאות:

ארגונים:

gcloud resource-manager org-policies describe compute.requireSslPolicy \
    --effective \
    --organization=ORGANIZATION_ID

לתיקיות:

gcloud resource-manager org-policies describe compute.requireSslPolicy \
    --effective \
    --folder=FOLDER_ID

לפרויקטים:

gcloud resource-manager org-policies describe compute.requireSslPolicy \
    --effective \
    --project=PROJECT_ID

כדי למחוק את המדיניות מהמשאב (ארגון, תיקייה או פרויקט), מריצים את הפקודות הבאות:

ארגונים:

gcloud resource-manager org-policies delete compute.requireSslPolicy \
    --organization=ORGANIZATION_ID

לתיקיות:

gcloud resource-manager org-policies delete compute.requireSslPolicy \
    --folder=FOLDER_ID

לפרויקטים:

gcloud resource-manager org-policies delete compute.requireSslPolicy \
    --project=PROJECT_ID

כדי להגדיר אילוצים מותאמים אישית, אפשר לעיין במאמר שימוש באילוצים מותאמים אישית כדי להגביל את היכולות של TLS.

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

מידע נוסף על היררכיית המשאבים שחלה על מדיניות הארגון זמין במאמר היררכיית המשאבים.
סקירה כללית של מדיניות הארגון ואילוצים מופיעה במאמר מבוא לשירות של מדיניות הארגון.
הוראות לעבודה עם אילוצים וכללי מדיניות ארגון במסוף Google Cloud זמינות במאמר מבוא לשירות של מדיניות הארגון.
הוראות לעבודה עם אילוצים וכללי מדיניות ארגון ב-gcloud מפורטות במאמר שימוש באילוצים.
רשימה מלאה של האילוצים הזמינים מופיעה במאמר אילוצים של מדיניות הארגון.
למידע על רכיבי ה-method של ה-API שרלוונטיים למדיניות הארגון, אפשר לעיין במאמרי העזרה של Cloud Resource Manager API.

אילוצים של מדיניות הארגון לגבי Cloud Load Balancing קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

הגבלת סוגים של מאזני עומסים

הודעות שגיאה ב-GKE

השבתת איזון עומסים גלובלי

הגבלת סוגי הפריסות של העברת פרוטוקולים

אכיפת הגבלות ב-VPC משותף

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

הגבלת תת-רשתות של VPC משותף

הגבלת גישה ל-backend buckets ולשירותי backend בין פרויקטים

הגבלת שירותים לקצה עורפי ב-VPC משותף

הגבלת ההסרה של מנעול למניעת מחיקה של פרויקט VPC משותף

הגבלת יכולות TLS באמצעות אילוצים בהתאמה אישית

שימוש בכללים בוליאניים במדיניות הארגון

ההרשאות שנדרשות למשימה הזו

המסוף

gcloud

הגדרת כללים של רשימות במדיניות הארגון

ההרשאות שנדרשות למשימה הזו

המסוף

gcloud

הגדרת מדיניות ארגונית להחלת מדיניות SSL על שרתי proxy של HTTPS ועל שרתי proxy של SSL

ההרשאות שנדרשות למשימה הזו

המסוף

gcloud

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

אילוצים של מדיניות הארגון לגבי Cloud Load Balancing

ההרשאות שנדרשות למשימה הזו

ההרשאות שנדרשות למשימה הזו

ההרשאות שנדרשות למשימה הזו