שיטות אימות של חשבונות שירות ב-Apigee Hybrid

בחירת שיטות אימות של חשבונות שירות ב-Apigee Hybrid

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

הסבר על אימות של חשבון שירות

‫Apigee Hybrid משתמש Google Cloud בחשבונות שירות כדי לאמת ולאשר רכיבים שפועלים באשכול Kubernetes. חשבונות השירות האלה ניגשים למשאבים של Google Cloud , כמו קטגוריות של Cloud Storage ו-Cloud Logging. כל חשבון שירות דורש תפקידים ספציפיים בניהול הזהויות והרשאות הגישה (IAM) כדי לבצע את הפונקציות שלו.

אפשרויות של שיטת אימות

‫Apigee hybrid תומך בכמה שיטות לאימות חשבונות שירות. כל שיטה מנהלת את המפתחות של חשבון השירות באופן שונה, ומציעה רמות שונות של אבטחה ומורכבות תפעולית. כשבוחרים שיטה, חשוב לקחת בחשבון את הפלטפורמה, את מצב האבטחה ואת התשתית הקיימת.

בטבלה הבאה מפורטות שיטות האימות הזמינות:

‏Method מיקום אחסון המפתחות תאימות לפלטפורמות ניהול מפתחות
סודות של Kubernetes סודות באשכול Kubernetes כל פלטפורמת Kubernetes ‫Kubernetes מנהל סודות, רוטציה ידנית
קובצי מפתח JSON של חשבון שירות מערכת הקבצים המקומית כל פלטפורמת Kubernetes סיבוב והפצה ידניים
Vault HashiCorp Vault כל פלטפורמת Kubernetes ניהול סודות ב-Vault, רוטציה ידנית
איחוד זהויות של עומסי עבודה ל-GKE Google Cloud IAM Google Kubernetes Engine (GKE) ‫Google Cloud manages, no key files needed
איחוד שירותי אימות הזהות של עומסי עבודה בפלטפורמות אחרות Google Cloud IAM ‫AKS,‏ EKS,‏ OpenShift או פלטפורמות אחרות של Kubernetes ‫Google Cloud manages, no key files needed

אחסון מפתחות של חשבונות שירות בסודות של Kubernetes

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

רכיבים היברידיים מפנים לסודות האלה באמצעות המאפיינים serviceAccountRef ו-envs[].serviceAccountRefs בקובץ overrides.yaml. מערכת Kubernetes מנהלת את ההפצה של הסודות האלה לפודים המתאימים.

לדוגמה:

logger:
  serviceAccountRef: "my-project-apigee-logger-key"

כדי להשתמש בשיטה הזו, ראו אחסון מפתחות של חשבונות שירות בסודות של Kubernetes.

קובצי מפתח JSON של חשבון שירות

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

ממקמים את קובץ ה-JSON של המפתח הפרטי של כל חשבון שירות בספרייה שאליה יש גישה לרכיבי Apigee Hybrid. צריך לציין את הנתיב לקבצים האלה בהגדרות של overrides.yaml באמצעות המאפיינים serviceAccountPath ו-envs[].serviceAccountPaths.

לדוגמה:

logger:
  serviceAccountPath: "my-project-apigee-logger.json"

אתם יכולים ליצור ולהוריד את קובצי המפתחות של חשבון השירות באמצעות הכלי create-service-account שמסופק עם Apigee hybrid. מידע נוסף זמין במאמר create-service-account.

אחסון מפתחות של חשבונות שירות ב-Vault

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

תצטרכו ליצור סודות, כללי מדיניות ותפקידים נפרדים ב-Vault עבור הרכיבים ברמת הארגון וברמת הסביבה. אתם מפנים לסודות האלה בהגדרות של overrides.yaml באמצעות המאפיינים serviceAccountSecretProviderClass ו-envs[].serviceAccountSecretProviderClass.

לדוגמה:

serviceAccountSecretProviderClass: apigee-orgsakeys-spc

envs:
- name: my-env
  serviceAccountSecretProviderClass: apigee-envsakeys-my-env-spc

איך מאחסנים מפתחות של חשבונות שירות ב-Vault

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

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

בשיטה הזו צריך לקשר כל חשבון שירות של Kubernetes לחשבון שירות ספציפי של Google Cloud . תהליך ההתקנה של Apigee Hybrid יוצר את חשבונות השירות של Kubernetes שספציפיים להתקנה שלכם כשאתם מתקינים את תרשימי ה-Helm של Apigee Hybrid. כשמריצים את הפקודה helm install או helm upgrade עם הדגל --dry-run לכל תרשים, הפלט יכלול את הפקודות לקישור חשבונות שירות של Kubernetes לחשבונות שירות של רכיב Apigee Hybrid הספציפי בתרשים. Google Cloud

כדי להפעיל איחוד זהויות של עומסי עבודה ל-GKE, צריך להשתמש במאפיין gcp.workloadIdentity.enabled בקובץ overrides.yaml.

לדוגמה:

gcp:
  projectID: my-project
  region: us-west1
  workloadIdentity:
    enabled: true

מידע נוסף זמין במאמר בנושא הפעלת איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE.

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

איחוד שירותי אימות הזהות של עומסי עבודה מרחיב את היתרונות של Workload Identity ל-GKE גם לאשכולות Kubernetes שפועלים מחוץ ל- Google Cloud, כמו Azure Kubernetes Service ‏ (AKS), ‏ Amazon Elastic Kubernetes Service ‏ (EKS) או OpenShift. השיטה הזו מאפשרת לאשכול שאינו GKE לבצע אימות ב- Google Cloudבאמצעות ספק ה-OIDC של האשכול, כדי להגדיר יחסי אמון בין ספק הזהויות של האשכול לבין Google Cloud. אחרי ההגדרה הראשונית, השיטה הזו מבטלת את הצורך בקובצי מפתחות של חשבונות שירות. Google Cloud

אפשר להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה עם:

  • קובצי תצורה של פרטי כניסה (במקום קובצי מפתח של חשבון שירות)
  • סודות של Kubernetes
  • Vault

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

מפעילים את איחוד שירותי אימות הזהות של עומסי עבודה בקובץ overrides.yaml באמצעות המאפיינים gcp.federatedWorkloadIdentity.enabled,‏ gcp.federatedWorkloadIdentity.audience ו-gcp.federatedWorkloadIdentity.credentialSourceFile.

לדוגמה:

gcp:
  projectID: my-project
  region: us-west1
  federatedWorkloadIdentity:
    enabled: true
    audience: "//iam.googleapis.com/projects/123123123123/locations/global/workloadIdentityPools/my-wi-pool/providers/my-wi-provider"
    credentialSourceFile: "/var/run/service-account/token"

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

בחירה של שיטת אימות

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

  • בפריסות של GKE, איחוד שירותי אימות הזהות של עומסי עבודה ל-GKE מציע גישה מאובטחת ויעילה. הוא מבטל את הצורך בניהול ישיר של קובצי מפתחות של חשבונות שירות.
  • בפריסות של Kubernetes שאינן GKE (AKS, ‏ EKS, ‏ OpenShift), איחוד שירותי אימות הזהות של עומסי עבודה מספק חוויית אימות דומה ללא מפתחות. השיטה הזו מומלצת לסביבות האלה.
  • אם איחוד זהויות של עומסי עבודה ל-GKE או איחוד זהויות של עומסי עבודה לא זמינים, מומלץ להשתמש ב-Vault לניהול מרכזי של מפתחות ולאוטומציה.
  • אם רוצים פריסות פשוטות יותר או אם אין לכם הגדרת Vault, אחסון מפתחות בסודות של Kubernetes מספק פתרון מקורי של Kubernetes. השיטה הזו מציעה אבטחה טובה יותר מאחסון קבצים ישיר.
  • קובצי מפתחות של חשבונות שירות ישירים מתאימים לבדיקות ראשוניות או לסביבות שבהן שיטות אחרות לא אפשריות. עם זאת, בשיטה הזו נדרש ניהול ידני קפדני של המפתחות ורוטציה שלהם.

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