יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

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

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

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

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

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

מאזני עומסים של אפליקציות (ALB)
- ‫EXTERNAL_MANAGED_HTTP_HTTPS למאזן עומסים חיצוני אזורי של אפליקציות (ALB)
- ‫INTERNAL_HTTP_HTTPS למאזן עומסים פנימי אזורי של אפליקציות
מאזני עומסים של רשת בשרת proxy
- ‫REGIONAL_EXTERNAL_MANAGED_TCP_PROXY למאזן עומסי רשת אזורי חיצוני בשרת proxy עם TCP proxy
- ‫REGIONAL_INTERNAL_MANAGED_TCP_PROXY למאזן עומסי רשת אזורי פנימי בשרת proxy עם שרת proxy ל-TCP
מאזני עומסים ברשת להעברת סיגנל ללא שינוי
- ‫EXTERNAL_NETWORK_TCP_UDP למאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי
- ‫INTERNAL_TCP_UDP למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי

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

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

אחרי שמגדירים את המדיניות, היא נאכפת כשמוסיפים אתCloud de Confiance כללי ההעברה המתאימים. האילוץ לא נאכף על הגדרות קיימות של 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: השם של מאזן העומסים

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

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

שם: הגבלת העברת פרוטוקולים על סמך סוג כתובת ה-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. המגבלה לא משפיעה רטרואקטיבית על הפניות הקיימות לשירותי קצה עורפיים או לדלי קצה עורפיים בין פרויקטים.

המגבלה הזו חלה על כל סוגי הפריסות, כולל 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.

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

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

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

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

המסוף

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

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

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

gcloud

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

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

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

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

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

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

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

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

המסוף

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

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

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 ביעד

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

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

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

המסוף

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

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

מעבר למדיניות הארגון
בשדה 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.

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

מידע נוסף על היררכיית המשאבים שחלה על מדיניות הארגון זמין במאמר היררכיית המשאבים.
סקירה כללית של מדיניות הארגון ואילוצים מופיעה במאמר מבוא לשירות של מדיניות הארגון.
הוראות לעבודה עם אילוצים וכללי מדיניות ארגון במסוף Cloud de Confiance זמינות במאמר מבוא לשירות של מדיניות הארגון.
הוראות לעבודה עם אילוצים וכללי מדיניות ארגון ב-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

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

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

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

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