מידע על איחוד זהויות של עומסי עבודה ל-GKE

במסמך הזה מוסבר על איחוד זהויות של עומסי עבודה ל-GKE, כולל איך הוא פועל, איך ההפעלה שלו משפיעה על אשכולות GKE ואיך מעניקים תפקידים לישויות של Kubernetes במדיניות של ניהול הזהויות והרשאות הגישה (IAM). ברוב המקרים, מומלץ להשתמש באיחוד זהויות של עומסי עבודה ל-GKE כדי לאבטח ולנהל את הגישה של עומסי העבודה שפועלים ב-GKE לשירותים. Google Cloud

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

הסברים על המונחים

בדף הזה מוסבר ההבדל בין חשבונות שירות של Kubernetes לבין חשבונות שירות של ניהול זהויות והרשאות גישה (IAM).

חשבונות שירות של Kubernetes
משאבי Kubernetes שמספקים זהות לתהליכים שפועלים בקבוצות ה-Pod של GKE.
חשבונות שירות ב-IAM
Google Cloud משאבים שמאפשרים לאפליקציות לבצע קריאות מורשות ל-Google Cloud APIs.

מה זה איחוד זהויות של עומסי עבודה ל-GKE?

יכול להיות שאפליקציות שפועלות ב-GKE יצטרכו גישה לממשקי API שלGoogle Cloud , כמו Compute Engine API, ‏ BigQuery Storage API או ממשקי API של Machine Learning.

איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE מאפשר להשתמש במדיניות IAM כדי להעניק לעומסי עבודה של Kubernetes באשכול GKE גישה ל-API ספציפיים שלGoogle Cloud Google בלי להזדקק להגדרה ידנית או לשיטות פחות מאובטחות כמו קובצי מפתח של חשבון שירות. שימוש באיחוד זהויות של עומסי עבודה ל-GKE מאפשר להקצות זהויות והרשאות שונות ומפורטות לכל אפליקציה באשכול.

איחוד זהויות של עומסי עבודה ל-GKE מחליף את הצורך בשימוש בהסתרת מטא-נתונים. המטא-נתונים הרגישים שמוגנים על ידי הסתרת מטא-נתונים מוגנים גם על ידי איחוד זהויות של עומסי עבודה ל-GKE.

איחוד זהויות של עומסי עבודה ל-GKE זמין דרך איחוד זהויות של עומסי עבודה ב-IAM, שמספק זהויות לעומסי עבודה שפועלים בסביבות בתוך Google Cloudומחוץ לה. אתם יכולים להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה ב-IAM כדי לבצע אימות מאובטח ל-ממשקי API נתמכים Google Cloud מעומסי עבודה שפועלים, למשל, ב-AWS, ב-Azure וב-Kubernetes בניהול עצמי. ב-GKE,‏Google Cloud מנהל בשבילכם את מאגר הזהויות של עומסי העבודה ואת הספק, ולא נדרש ספק זהויות חיצוני.

איך פועל איחוד זהויות של עומסי עבודה ל-GKE

כשמפעילים איחוד זהויות של עומסי עבודה ל-GKE באשכול, GKE מבצע את הפעולות הבאות:

  • יוצר מאגר זהויות של עומסי עבודה קבוע עבור פרויקט Google Cloudשל האשכול בפורמט הבא:

    PROJECT_ID.svc.id.goog

    מאגר הזהויות של עומסי העבודה מספק פורמט שמות שמאפשר ל-IAM להבין את פרטי הכניסה של Kubernetes ולסמוך עליהם. ‫GKE לא מוחק את מאגר הזהויות של עומסי עבודה הזה גם אם מוחקים את כל האשכולות בפרויקט.

  • רושם את אשכול GKE כספק זהויות במאגר הזהויות של עומסי העבודה.

  • פריסה של שרת המטא-נתונים של GKE, שמיירט בקשות לפרטי כניסה מעומסי עבודה, בכל צומת.

יצירת מדיניות הרשאות ב-IAM לגבי Google Cloud משאבים

כדי לספק גישה באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE, אתם יוצרים מדיניות הרשאה של IAM שמעניקה גישה למשאב ספציפי Google Cloud לגורם ראשי שמתאים לזהות של האפליקציה שלכם. לדוגמה, אפשר לתת הרשאות קריאה בקטגוריה של Cloud Storage לכל קבוצות ה-Pod שמשתמשות ב-database-reader Kubernetes ServiceAccount.

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

שימוש בתנאים במדיניות IAM

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

תנאים יכולים להיות שימושיים גם אם מגדירים את מדיניות ההרשאות ברמת הפרויקט, התיקייה או הארגון, במקום במשאבים ספציפיים כמו סודות ב-Secret Manager או קטגוריות ב-Cloud Storage.

כדי להוסיף תנאי למדיניות ההרשאות, אפשר להיעזר במקורות המידע הבאים:

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

דוגמאות לביטויי תנאי
מתן גישה לפני השעה שצוינה 
request.time < timestamp('TIMESTAMP')

מחליפים את TIMESTAMP בחותמת זמן בפורמט UTC, כמו 2024-08-30T00:00:00.000Z.
מתן גישה אם למשאב בבקשה יש את התג שצוין 
resource.matchTag('TAG_KEY', 'TAG_VALUE')

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

  • ‫TAG_KEY: מפתח התג להתאמה, כמו env
  • ‫TAG_VALUE: הערך של התג, כמו dev

הפניה למשאבי Kubernetes בכללי מדיניות IAM

במדיניות IAM, כדי לבחור משאב Kubernetes, צריך להפנות אליו באמצעות מזהה חשבון משתמש של IAM. התחביר של המזהה הזה הוא:

PREFIX://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/example-project.svc.id.goog/SELECTOR

בדוגמה הזו, חשוב לשים לב לשדות הבאים:

  • ‫PREFIX: הערך צריך להיות principal או principalSet, בהתאם למשאב שבוחרים. ‫principal הוא משאב ספציפי, כמו ServiceAccount יחיד. ‫principalSet מיועד למספר משאבים ששייכים למשאב שצוין, כמו כל ה-Pods באשכול ספציפי.
  • ‫SELECTOR: מחרוזת שבוחרת סוג של חשבון משתמש. לדוגמה, kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID בוחר ServiceAccount לפי ה-UID שלו.

בטבלה הבאה מוצגים סוגי הגורמים המורשים הנתמכים ב-GKE:

סוג המזהה של חשבון המשתמש תחביר
כל קבוצות ה-Pod שמשתמשות בחשבון שירות ספציפי של Kubernetes בוחרים את חשבון השירות לפי שם: 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

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

  • ‫PROJECT_NUMBER: מספר הפרויקט. כדי לקבל את מספר הפרויקט, אפשר לעיין במאמר בנושא זיהוי פרויקטים.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫NAMESPACE: מרחב השמות של Kubernetes.
  • ‫SERVICEACCOUNT: השם של Kubernetes ServiceAccount.
Select the ServiceAccount by UID: 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

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

  • ‫PROJECT_NUMBER: מספר הפרויקט. כדי לקבל את מספר הפרויקט, אפשר לעיין במאמר בנושא זיהוי פרויקטים.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫SERVICEACCOUNT_UID: ה-UID של אובייקט ServiceAccount בשרת ה-API.
כל ה-Pods במרחב שמות, ללא קשר לחשבון השירות או לאשכול 
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/namespace/NAMESPACE

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

  • ‫PROJECT_NUMBER: מספר הפרויקט. כדי לקבל את מספר הפרויקט, אפשר לעיין במאמר בנושא זיהוי פרויקטים.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫NAMESPACE: מרחב השמות של Kubernetes.
כל ה-Pods באשכול מסוים 
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.cluster/https://container.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME

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

  • ‫PROJECT_NUMBER: מספר הפרויקט. כדי לקבל את מספר הפרויקט, אפשר לעיין במאמר בנושא זיהוי פרויקטים.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫CLUSTER_NAME: השם של אשכול GKE.
  • ‫LOCATION: המיקום של האשכול.

תהליך העברת פרטי הכניסה

כשעומס עבודה שולח בקשה לגישה ל-API של Google Cloud , למשל כשמשתמשים ב Google Cloud ספריית לקוח, מתבצעים שלבי האימות הבאים:

איך עומס עבודה מקבל אסימון של חשבון שירות ב-IAM באמצעות Workload Identity.
איור 1: איך עומס עבודה מקבל אסימון גישה מאוחד באמצעות איחוד זהויות של עומסי עבודה ל-GKE.
  1. Application Default Credentials‏ (ADC) מבקש אסימון גישה משרת המטא-נתונים של Compute Engine שפועל במכונה הווירטואלית. Google Cloud
  2. שרת המטא-נתונים של GKE מיירט את בקשת האסימון ומבקש משרת ה-API של Kubernetes אסימון Kubernetes ServiceAccount שמזהה את עומס העבודה ששלח את הבקשה. פרטי הכניסה האלה הם אסימון אינטרנט מסוג JSON‏ (JWT) שחתום על ידי שרת ה-API.
  3. שרת המטא-נתונים של GKE משתמש בSecurity Token Service כדי להחליף את אסימון ה-JWT באסימון גישה מאוחד לזמן קצר, שמפנה לזהות של עומס העבודה ב-Kubernetes.

יכול להיות שיחולו מגבלות על אסימון הגישה המאוחד שמוחזר על ידי Security Token Service כשמנסים לגשת לשירותים מסוימים של Google Cloud Google, כפי שמתואר במאמר מוצרים נתמכים ומגבלות. אם לשירות שבחרתם יש מגבלות, אתם יכולים להגדיר התחזות לחשבון שירות. Google Cloud השיטה הזו יוצרת אסימון גישה לחשבון שירות ב-IAM, שעומס העבודה יכול להשתמש בו כדי לגשת לשירות היעד. לפרטים, ראו קישור של חשבונות שירות ב-Kubernetes ל-IAM.

לאחר מכן, עומס העבודה יכול לגשת לכל Google Cloud ממשקי ה-API שאליהם יש גישה למזהה החשבון הראשי של IAM של עומס העבודה.

מכסה ל-Exchange Token API ב-Security Token Service

ל-Exchange Token API ב-Security Token Service יש מגבלת מכסה של 6,000 בקשות לדקה. אם מופיעות שגיאות QUOTA_EXCEEDED, אפשר לבקש להגדיל את המכסה Token exchange requests per minute דרך הדף Quotas & System Limits (מכסות ומגבלות מערכת).

זהות זהה

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

לדוגמה, נסתכל על התרשים הבא. קלאסטרים A ו-B שייכים לאותו מאגר זהויות של עומסי עבודה. Google Cloud מזהה אפליקציות שמשתמשות ב-back-ksa ServiceAccount במרחב השמות backend של קלאסטר A ושל קלאסטר B כאותה זהות. מערכת IAM לא מבדילה בין האשכולות שמבצעים את הקריאות.

דיאגרמה שממחישה זהות זהה בתוך מאגר זהויות של עומסי עבודה
איור 2: גישה לממשקי API באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE. Google Cloud

הזהות הזהה הזו גם אומרת שצריך להיות לכם אמון בכל אשכול במאגר זהויות של עומסי עבודה ספציפי. לדוגמה, אם אשכול חדש, Cluster C בדוגמה הקודמת, היה בבעלות צוות לא מהימן, הוא יכול היה ליצור מרחב שמות backendולגשת לממשקי API של Google Cloud back-ksaServiceAccount, בדיוק כמו Cluster A ו-Cluster B.

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

שרת מטא-נתונים של GKE

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

שרת המטא-נתונים של GKE פועל כ-DaemonSet, עם Pod אחד בכל צומת Linux או שירות Windows מקורי בכל צומת Windows באשכול. שרת המטא-נתונים מיירט בקשות HTTP אל http://metadata.google.internal (169.254.169.254:80). לדוגמה, הבקשה GET /computeMetadata/v1/instance/service-accounts/default/token מאחזרת אסימון לחשבון השירות של IAM שה-Pod מוגדר להתחזות אליו. התעבורה לשרת המטא-נתונים של GKE אף פעם לא יוצאת מהמכונה הווירטואלית שמארחת את ה-Pod.

משך החיים של הטוקן

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

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

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

  1. בודקים אם פג התוקף של אסימון הגישה אחרי תקופה של 3 דקות ו-45 שניות. הפרמטר exp במטען הייעודי (payload) של הטוקן מציין את חותמת הזמן של תפוגת הטוקן.
  2. אם התוקף של האסימון עומד לפוג תוך 3 דקות ו-45 שניות, צריך לשלוח בקשה לאסימון.

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

מטא-נתונים של מופע

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

http://metadata.google.internal/computeMetadata/v1/instance/

הערך תיאור
hostname

שם המארח של הצומת.
id

המזהה הייחודי של הצומת.
service-accounts/

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

  • aliases
  • email: כתובת האימייל של חשבון השירות.
  • ‫identity: אסימון רשת מבוסס JSON‏ (JWT) שייחודי לצומת. חובה לכלול את הפרמטר audience בבקשה. לדוגמה, ?audience=http://www.example.com.
  • ‫scopes: היקפי הגישה שהוקצו לחשבון השירות.
  • ‫token: אסימון הגישה מסוג OAuth 2.0 לאימות של עומסי העבודה.
zone

התחום (zone) של Compute Engine שבו נמצא הצומת של GKE.

מאפייני המכונה

מאפייני המופע מאוחסנים בספרייה הבאה.

http://metadata.google.internal/computeMetadata/v1/instance/attributes/

הערך תיאור
cluster-location

התחום (zone) או האזור של Compute Engine שבו נמצא האשכול.
cluster-name

השם של אשכול GKE.
cluster-uid

ה-UID של אשכול GKE.

המאפיינים שמפורטים בטבלה הם המאפיינים הנתמכים היחידים. אם תנסו לגשת למאפיינים שלא נתמכים, יווצר יומן רישום של שגיאה 404 ב-Pod‏ gke-metadata-server במרחב השמות kube-system. השגיאה דומה לזו:

HTTP/404: generic::not_found: no child "", Reason: "NOT_FOUND", UserMessage: "Not Found"

אם אתם משתמשים ב-istio-proxy, יכול להיות שתופיע הודעת שגיאה כמו זו:

Error fetching GCP Metadata property gcp_gce_instance_template: metadata: GCE metadata "instance/attributes/UNSUPPORTED_ATTRIBUTE" not defined

מטא-נתונים של הפרויקט

מטא-נתונים של פרויקט אשכול מאוחסנים בספרייה הבאה.

http://metadata.google.internal/computeMetadata/v1/project/

הערך תיאור
project-id

מזהה הפרויקט ב- Google Cloud .
numeric-project-id

מספר הפרויקט Google Cloud .

מגבלות של איחוד זהויות של עומסי עבודה ל-GKE

  • אי אפשר לשנות את השם של מאגר זהויות של עומסי עבודה ש-GKE יוצר עבור פרויקט Google Cloud .

  • אם מקשרים חשבונות שירות של Kubernetes לחשבונות שירות של IAM כדי להגדיר איחוד זהויות של עומסי עבודה ל-GKE, שרת המטא-נתונים של GKE מחזיר את הערך SERVICEACCOUNT_NAME.svc.id.goog כמזהה של חשבון השירות. המזהה הזה לא משתמש בתחביר הסטנדרטי של מזהה חשבון משתמש ב-IAM, ולכן יכולות להיות שגיאות בפעולות מסוימות שמתבצעות באופן פרוגרמטי. כדי לקבל את מזהה חשבון השירות כמזהה של חשבון משתמש ב-IAM, מוסיפים את ההערה iam.gke.io/return-principal-id-as-email: "true" ל-ServiceAccount של Kubernetes.

  • כש-GKE מפעיל את שרת המטא-נתונים של GKE במאגר צמתים, ל-Pods כבר אין גישה לשרת המטא-נתונים של Compute Engine. במקום זאת, שרת המטא-נתונים של GKE מיירט בקשות שנשלחות מהפודים האלה לנקודות קצה של מטא-נתונים, למעט פודים שפועלים ברשת המארחת.

  • כשמשתמשים במנהל ההתקן של ה-CSI של Cloud Storage FUSE עם אשכולות GKE רגילים בגרסה 1.33.3-gke.1226000 ואילך, קבוצות ה-Pod שפועלות ברשת המארחת (hostNetwork: true) יכולות לבצע אימות באמצעות חשבון השירות שלהן ב-Kubernetes. מידע נוסף זמין במאמר בנושא הגדרת גישה ל-Pods עם רשת מארחת.

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

  • סוכני הרישום ביומן והניטור המובנים ב-GKE ממשיכים להשתמש בחשבון השירות של הצומת.

  • איחוד זהויות של עומסי עבודה ל-GKE מחייב הגדרה ידנית של Knative Serving כדי להמשיך לפרסם מדדי בקשות.

  • איחוד זהויות של עומסי עבודה ל-GKE מגדיר מגבלה של 500 חיבורים בו-זמניים לשרת המטא-נתונים של GKE לכל צומת. שיחות נוספות בו-זמניות שחורגות מהמגבלה הזו מוכנסות לתור המתנה לעיבוד מאוחר יותר. מנגנון התור הזה עלול לגרום לשגיאות HTTP/499 אם זמן קצוב לתפוגה של הלקוח יגיע לפני ששרת המטא-נתונים של GKE יוכל לעבד את הבקשה.

  • שרת המטא-נתונים של GKE משתמש במשאבי זיכרון באופן יחסי למספר הכולל של חשבונות השירות של Kubernetes באשכול. אם באשכול יש יותר מ-3,000 חשבונות שירות של Kubernetes, יכול להיות ש-kubelet יסיים את הפעולה של קבוצות ה-Pod של שרת המטא-נתונים. אפשר למצוא פתרונות במאמר בנושא פתרון בעיות.

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

חלופות ל-Workload Identity Federation ל-GKE

אפשר להשתמש באחת מהחלופות הבאות לאיחוד זהויות של עומסי עבודה ל-GKE כדי לגשת ל-Google Cloud APIs מ-GKE. מומלץ להשתמש ב-Workload Identity Federation ל-GKE כי החלופות האלה מחייבות אתכם להתפשר על אבטחה מסוימת.

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