‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הגדרת מדיניות הארגון

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

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

‫Google Distributed Cloud (GDC) air-gapped לא מספק ממשק משתמש במסוף או CLI ייעודי ליצירה ולניהול של מדיניות ארגונית. אתם צריכים להשתמש ב-Kubernetes API או ב-kubectl CLI.

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

ניהול זהויות והרשאות גישה (IAM) ומדיניות ארגונית ממלאים פונקציות משלימות של גישה וניהול:

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

לפני שמתחילים

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

שליחת בקשה לתפקידים ב-IAM

צריך לפנות לאדמין IAM בארגון ולבקש את תפקידי ה-IAM הבאים בהתאם למשימות שצריך לבצע:

אדמין של מדיניות שירות מוגבל (gdchrestrictedservice-policy-admin): יצירה, עדכון ומחיקה של מדיניות שירות מוגבלת.
אדמין של מדיניות הגבלה לפי מאפיינים (gdchrestrictbyattributes-policy-admin): יצירה, עדכון ומחיקה של כללי מדיניות של בקרת גישה שמבוססת על מאפיינים.

הכנת הסביבה

מורידים ומתקינים את ה-gdcloud CLI, אם עוד לא עשיתם זאת.
מתקינים את kubectl CLI.
יוצרים קובץ kubeconfig כדי להגדיר גישה ל-kubectl CLI.

הגדרת מדיניות

ב-GDC אפשר להגדיר שני סוגים של מדיניות ארגונית:

מדיניות שירותים מוגבלים (GDCHRestrictedService): מגבילה את השירותים שבהם אפשר להשתמש או לשנות אותם באשכול.
מדיניות של בקרת גישה מבוססת-מאפיינים (GDCHRestrictByAttributes): מגבילה באופן מותנה את הגישה למשאבים באשכול על סמך מאפייני נושא שממופים מספק הזהויות.

הגדרת מדיניות שירות מוגבלת

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

‫GDCHRestrictedService תומך בפעולות CREATE,‏ UPDATE ו-DELETE. כדי להגביל פעולות קריאה של GET ושל LIST, משתמשים בקישורי תפקידים ב-IAM כדי להעניק ולבטל גישה.

הגדרת מדיניות לשירות מוגבל:

הגדרת קובץ המניפסט של המדיניות:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GDCHRestrictedService
metadata:
  name: POLICY_NAME
spec:
  match:
    kinds:
      - apiGroups:
          - "API_GROUP"
        kinds:
          - "KIND"
  parameters:
    disabledOperations:
      - DISABLED_OPERATION

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

‫POLICY_NAME: השם של מדיניות הארגון.
‫API_GROUP: קבוצת ה-API של השירות שרוצים להגביל, כמו שמופיע בטבלה הבאה של השירותים הנתמכים.
‫KIND: סוג המשאב שרוצים להגביל, כפי שמופיע בטבלה הבאה של השירותים הנתמכים.
‫DISABLED_OPERATION: קבוצות הפעולות שהמדיניות הזו חוסמת. הערכים המותרים הם CREATE,‏ UPDATE ו-DELETE. ערך ברירת המחדל של השדה disabledOperations הוא *. כדי להשבית שירות באופן מלא, צריך לציין את CREATE, UPDATE ו-DELETE (ואת כל הסוגים שלו).

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

מדיניות GDCHRestrictedService תומכת בקבוצת המשנה הבאה של שירותים ב-GDC:

Service	API Group	kinds
Marketplace	`marketplace.gdc.goog`	`MarketplaceService`
Vertex AI Workbench	`aiplatform.gdc.goog`	`Notebook`
שירות מסד נתונים – Postgres	`postgresql.dbadmin.gdc.goog`	`DBCluster` `BackupPlan` `Import` `Restore`
Transfer Appliance	`system.gpc.gke.io`	`TransferApplianceRequest`
גיבוי	`backup.gdc.goog`	`BackupRepositoryManager`
Dataproc Container for Spark (שירות Marketplace)	`sparkoperator.k8s.io`	`SparkApplication`

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

בדוגמה הבאה, ההגבלה היא על עדכונים לשירותים ב-Marketplace:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GDCHRestrictedService
metadata:
  name: no-update-to-marketplace-service
spec:
  match:
    kinds:
    - apiGroups:
      - "marketplace.gdc.goog"
      kinds:
      - MarketplaceService
  parameters:
    disabledOperations:
      - "UPDATE"

מחילים את המדיניות באמצעות ה-CLI של kubectl:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f POLICY_NAME.yaml
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_KUBECONFIG: קובץ ה-kubeconfig של האשכול שבו רוצים להחיל את המדיניות
- ‫POLICY_NAME: השם של קובץ מדיניות הארגון

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

סוג המדיניות GDCHRestrictByAttributes מאפשר ליצור מדיניות ABAC כדי להגביל באופן מותנה את הגישה למשאבים על סמך מאפייני הנושא. לדוגמה, אפשר להשתמש בסוג המדיניות הזה כדי להגביל פעולות כתיבה או שינוי בקטגוריות אחסון, כך שרק משתמשים או חשבונות שירות עם מאפייני זהות ספציפיים (כמו citizenship=USA או citizenship=UK) יוכלו לבצע אותן.

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

הגדרת מדיניות של בקרת גישה מבוססת-מאפיינים:

יוצרים קובץ JSON של תיקון כדי למפות מאפייני זהות מותאמים אישית למשאב IdentityProviderConfig:
```
cat <<EOF > attributeMapping-patch.json
{
  "CUSTOM_ATTRIBUTE": "assertion[\"CUSTOM_ATTRIBUTE\"]"
}
EOF
```
מחליפים את CUSTOM_ATTRIBUTE בשם של מאפיין הזהות למיפוי, כמו citizenship.
מבצעים תיקון (patch) למשאב IdentityProviderConfig במרחב השמות platform:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG patch \
    IdentityProviderConfig IDENTITY_PROVIDER_CONFIG_NAME \
    -n platform --type=json \
    -p '[{"op":"add","path":"/spec/oidc/attributeMapping", "value": '"$(cat attributeMapping-patch.json)"'}]'
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_KUBECONFIG: קובץ ה-kubeconfig של האשכול שבו נמצא ספק הזהויות
- ‫IDENTITY_PROVIDER_CONFIG_NAME: השם של משאב IdentityProviderConfig
הגדרת קובץ המניפסט של המדיניות:
```
apiVersion: constraints.global.gatekeeper.sh/v1beta1
kind: GDCHRestrictByAttributes
metadata:
  name: POLICY_NAME
spec:
  match:
    kinds:
      - apiGroups:
          - "API_GROUP"
        kinds:
          - "KIND"
  parameters:
    attributes:
      - CUSTOM_ATTRIBUTE
    attributeValues:
      - ALLOWED_ATTRIBUTE_VALUE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫POLICY_NAME: השם של מדיניות הארגון.
- ‫API_GROUP: קבוצת ה-API של המשאבים שרוצים להגביל, כמו object.gdc.goog.
- ‫KIND: סוג המשאב שרוצים להגביל, למשל Bucket.
- ‫CUSTOM_ATTRIBUTE: מאפיין הנושא המותאם אישית שממופה מספק הזהויות, כמו citizenship.
- ‫ALLOWED_ATTRIBUTE_VALUE: הערך המותר של המאפיין המותאם אישית, למשל USA. בקשות של נושאים שהמאפיין שלהם לא תואם לאף אחד מהערכים המותרים נדחות.
כברירת מחדל, המדיניות חלה על כל מרחבי השמות באשכול. כדי להגדיר את היקף המדיניות למרחבי שמות או לפרויקטים ספציפיים, אפשר לעיין במאמר בנושא הגדרת היקף של מדיניות ארגונית באשכול.

בדוגמה הבאה, הגישה לשינוי משאבי Bucket במרחב השמות project-foo מוגבלת לנושאים עם המאפיין citizenship=USA או citizenship=UK:
```
apiVersion: constraints.global.gatekeeper.sh/v1beta1
kind: GDCHRestrictByAttributes
metadata:
  name: restrict-by-citizenship
spec:
  match:
    scope: Namespaced
    kinds:
      - apiGroups:
          - "object.gdc.goog"
        kinds:
          - Bucket
    namespaces:
      - project-foo
  parameters:
    attributes:
      - "citizenship"
    attributeValues:
      - "USA"
      - "UK"
```
מחילים את המדיניות באמצעות ה-CLI של kubectl:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f POLICY_NAME.yaml
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_KUBECONFIG: קובץ ה-kubeconfig של האשכול שבו רוצים להחיל את המדיניות
- ‫POLICY_NAME: השם של קובץ מדיניות הארגון

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

כשמגדירים מדיניות ארגונית, צריך להחליט אם היא תשפיע על כל מרחבי השמות, רק על מרחבי שמות ספציפיים או על כל מרחבי השמות למעט רשימה נתונה. כדי לעשות את זה, משתמשים בשילוב של הפרמטרים .spec.match.excludedNamespaces,‏ .spec.match.namespaceSelector,‏ .spec.match.namespaces ו-.spec.match.scope של הגדרת המדיניות.

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

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GDCHRestrictedService
metadata:
  name: db-restricted-to-dbas
spec:
  match:
    scope: Namespaced
    namespaceSelector:
      matchExpressions:
      # We are restricting the use of the service in namespaces that
      # don't have the owner: dba-team label
      - key: owner
        operator: NotIn
        values:
        - dba-team
    kinds:
    - apiGroups:
      - "postgresql.dbadmin.gdc.goog"
      kinds:
      - DBCluster
      - BackupPlan
      - Import
      - Restore
  parameters:
    disabledOperations:
      - "UPDATE"
      - "CREATE"
      - "DELETE"

ביטול של מדיניות קיימת

כדי להפסיק לאכוף מדיניות קיימת, מוחקים אותה באמצעות kubectl CLI. משתמשים בקובץ kubeconfig שנותן גישה לאשכול שבו מוגדרת המדיניות ולתפקיד ה-IAM שמתאים לסוג המדיניות (למשל gdchrestrictedservice-policy-admin או gdchrestrictbyattributes-policy-admin).

כדי למחוק מדיניות ארגונית:

kubectl --kubeconfig CLUSTER_KUBECONFIG delete \
    POLICY_TYPE/POLICY_NAME