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

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

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

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

ב-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 מנהל, לא נדרשים קובצי מפתחות
איחוד שירותי אימות הזהות של עומסי עבודה בפלטפורמות אחרות Google Cloud IAM ‫AKS,‏ EKS,‏ OpenShift או פלטפורמות אחרות של Kubernetes Google Cloud מנהל, לא נדרשים קובצי מפתחות

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

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

לדוגמה:

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

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

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

איחוד זהויות של עומסי עבודה מרחיב את היתרונות של איחוד זהויות של עומסי עבודה ל-GKE לאשכולות Kubernetes שפועלים מחוץ ל- Google Cloud, כמו Azure Kubernetes Service ‏ (AKS), ‏Amazon Elastic Kubernetes Service ‏ (EKS) או OpenShift. השיטה הזו מאפשרת לאשכול שאינו GKE לבצע אימות ב- Google Cloud באמצעות ספק ה-OIDC של האשכול, כדי להגדיר יחסי אמון בין ספק הזהויות של האשכול לבין 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. השיטה הזו מאובטחת יותר מאחסון קבצים ישיר.
  • קבצים ישירים של מפתחות לחשבונות שירות מתאימים לבדיקות ראשוניות או לסביבות שבהן אי אפשר להשתמש בשיטות אחרות. עם זאת, השיטה הזו דורשת ניהול ורוטציה ידניים וקפדניים של המפתחות.

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