בדף הזה מוסבר איך להגדיר אימות לאשכולות של Google Kubernetes Engine (GKE) מספקי זהויות (IdP) חיצוניים.
הדף הזה מיועד למנהלי פלטפורמות, למפעילים ולמנהלי זהויות וחשבונות שמשתמשים ב-IdP חיצוני שתומך ב-OpenID Connect (OIDC) או ב-Security Assertion Markup Language (SAML) 2.0.
לפני שתקראו את הדף הזה, חשוב שתכירו את המושגים הבאים שקשורים לאימות ול-OpenID:
שיטות אימות של IdP חיצוני ב-GKE
מומלץ – איחוד שירותי אימות הזהות של כוח עבודה
איחוד שירותי אימות הזהות של כוח עבודה הוא מאפיין של IAM שמאפשר לבצע אימות ב- Google Cloud מכל ספק זהויות (IdP) חיצוני שתומך ב-OIDC או ב-SAML 2.0. איחוד שירותי אימות הזהות של כוח עבודה לא דורש התקנה בתוך האשכול, פועל עם אשכולות Autopilot ואשכולות Standard, ומובנה ב- Google Cloud. לפרטים נוספים, קראו את המאמר איחוד שירותי אימות הזהות של כוח עבודה במסמכי התיעוד של IAM.
לא מומלץ – שירות הזהויות של GKE (הוצא משימוש)
באשכולות GKE Standard בלבד, GKE תומך גם ב-Identity Service for GKE. שירות הזהויות של GKE מוגבל לספקי זהויות שתומכים ב-OIDC, ומתקין רכיבים נוספים באשכול. ב-GKE מומלץ מאוד להשתמש באיחוד שירותי אימות הזהות של כוח העבודה במקום בשירות הזהויות של GKE. חשוב גם לשים לב למגבלה ידועה ב-Identity Service for GKE שמונעת התאמה לעומס (scaling).
לפני שמתחילים
לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:
- מפעילים את Google Kubernetes Engine API. הפעלת Google Kubernetes Engine API
- כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם כבר התקנתם את ה-CLI של gcloud, הריצו את הפקודה
gcloud components updateכדי לקבל את הגרסה העדכנית. יכול להיות שבגרסאות קודמות של ה-CLI של gcloud אי אפשר להריץ את הפקודות שבמסמך הזה.
לתשומת ליבכם
מערכות ללא ממשק משתמש לא נתמכות גם באיחוד שירותי אימות הזהות של כוח העבודה וגם בשירות הזהויות ל-GKE. תהליך אימות מבוסס-דפדפן מבקש מכם להביע הסכמה ולאשר את חשבון המשתמש שלכם.
שימוש באיחוד שירותי אימות הזהות של כוח העבודה ב-GKE
כדי להשתמש באיחוד שירותי אימות הזהות של כוח העבודה באשכולות GKE:
- מגדירים את איחוד שירותי אימות הזהות של כוח העבודה בארגון ובספק הזהויות החיצוני. הוראות מופיעות במאמר הגדרת איחוד שירותי אימות הזהות של כוח עבודה.
- מגדירים את הגישה מספק הזהויות החיצוני למסוף של Google Cloud איחוד שירותי אימות הזהות של כוח העבודה. פרטים נוספים זמינים במאמר איך להגדיר גישה של משתמש למסוף (המאוחד).
מגדירים את הגישה של המשתמשים באמצעות אחד ממנגנוני ההרשאה הבאים:
כדי שהמשתמשים יוכלו לגשת לאשכולות, צריך לבקש מהם לבצע את הפעולות הבאות:
- נכנסים ל-CLI של gcloud באמצעות הזהות המאוחדת.
- מגדירים את kubectl לאימות באשכול ספציפי באמצעות הפקודה
gcloud container clusters get-credentials.
הגדרת גישת משתמשים לאשכולות באמצעות RBAC
Google Cloud משתמש במזהי חשבונות משתמשים כדי לזהות משתמשים במאגרי הזהויות של כוח העבודה. אתם יכולים להפנות למזהי החשבונות הראשיים האלה בכללי המדיניות של Kubernetes RBAC או בכללי המדיניות של IAM, כדי לתת הרשאות לאנשים פרטיים או לקבוצות של משתמשים. עם RBAC, אי אפשר להפנות לטענות נכוֹנוּת מותאמות אישית אחרות שכלולות באסימונים של ה-IdP. ב-RBAC אפשר להשתמש במזהי חשבונות משתמשים רק למשתמשים ולקבוצות.
בטבלה הבאה מוצגות דוגמאות למזהי חשבונות ראשיים של משתמשים בודדים ושל קבוצות:
| זהות | מזהה של חשבון משתמש |
|---|---|
| משתמש יחיד | principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/subject/SUBJECT_ATTRIBUTE_VALUE מחליפים את מה שכתוב בשדות הבאים:
לדוגמה: principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com |
| כל המשתמשים בקבוצה | principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/group/GROUP_NAME מחליפים את מה שכתוב בשדות הבאים:
לדוגמה: principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre |
לכל מזהה של חשבון משתמש שנתמך באיחוד שירותי אימות הזהות של כוח העבודה, ראו ייצוג המשתמשים במאגרי כוח עבודה בכללי מדיניות IAM.
בדוגמה הבאה מוסבר איך לתת גישה לקריאה בלבד ברמת האשכול לסודות לכל הישויות במאגר כוח העבודה full-time-employees ששייכות לקבוצה sre בטוקן של ה-IdP שלהן.
שומרים את המניפסט הבא של ClusterRole בתור
secret-viewer-cluster-role.yaml:apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-viewer rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"]כל חשבון ראשי שאתם מקשרים ל-ClusterRole הזה יכול לראות את הסודות.
שומרים את המניפסט הבא של ClusterRoleBinding בתור
secret-viewer-cluster-role-binding.yaml:apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: users-view-secrets subjects: - kind: Group name: principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-viewer apiGroup: rbac.authorization.k8s.ioה-ClusterRoleBinding הזה מקצה את ה-ClusterRole
secret-viewerלכל משתמש ששייך לקבוצהsre.פורסים את ClusterRole ואת ClusterRoleBinding:
kubectl apply -f secret-viewer-cluster-role.yaml kubectl apply -f secret-viewer-cluster-role-binding.yaml
כניסה לאשכול ואימות שלו
- מבקשים מהמשתמש להיכנס באמצעות Google Cloud CLI.
המשתמש יכול להגדיר את kubectl לאימות באשכול באמצעות:
gcloud container clusters get-credentials
שימוש ב-Identity Service ל-GKE
כדי להגדיר את שירות הזהויות ל-GKE ולהשתמש בו באשכול GKE במצב Standard, מנהלי האשכול צריכים לבצע את הפעולות הבאות:
אחרי שמנהלי האשכולות מגדירים את שירות הזהויות ל-GKE, המפתחים יכולים להתחבר לאשכול ולאמת את הזהות שלהם.
אובייקטים של Kubernetes שנוצרו על ידי שירות זהות עבור GKE
בטבלה הבאה מתוארים האובייקטים של Kubernetes שנוצרים כשמפעילים את שירות הזהות ל-GKE באשכול:
| אובייקטים של Kubernetes | |
|---|---|
anthos-identity-service |
Namespaceמשמש לשירות הזהויות בפריסות של GKE. |
kube-public |
Namespaceמשמש לקובץ התצורה של הלקוח default. |
gke-oidc-envoy |
LoadBalancerנקודת הקצה לבקשות OIDC. חיצונית כברירת מחדל. אם יוצרים את נקודת הקצה באשכול בלי נקודת קצה של כתובת IP חיצונית, נקודת הקצה היא פנימית ל-VPC של האשכול. נוצר במרחב השמות anthos-identity-service. |
gke-oidc-service |
ClusterIPמאפשר תקשורת בין פריסת gke-oidc-envoy לפריסת gke-oidc-service.נוצר במרחב השמות anthos-identity-service. |
gke-oidc-envoy |
Deploymentמפעיל שרת proxy שחשוף ל- gke-oidc-envoy
LoadBalancer. מתקשר עם gke-oidc-service כדי לאמת אסימוני זהות. פועל כשרת proxy לשרת ה-API של Kubernetes, ומתחזה למשתמשים כשמועברות בקשות לשרת ה-API.נוצר במרחב השמות anthos-identity-service. |
gke-oidc-service |
Deploymentמאמת אסימוני זהות ומספק תגובת אימות לפעולות webhook למשאבי ClientConfig.נוצר במרחב השמות anthos-identity-service. |
gke-oidc-operator |
Deploymentהתאמה בין הגדרות הלקוח לבין gke-oidc-envoy
LoadBalancer. נוצר במרחב השמות anthos-identity-service. |
gke-oidc-certs |
Secretמכיל את רשות האישורים (CA) של האשכול ואת אישורי ה-TLS של LoadBalancer. נוצר במרחב השמות anthos-identity-service |
default |
ClientConfig CRDמכיל פרמטרים של OIDC כמו שיטת האימות המועדפת, הגדרת ספק הזהויות ומיפוי הצהרות של משתמשים וקבוצות. משמש לאימות של אסימון הזהות. מנהלי אשכולות משתמשים בהגדרות האלה כדי לקבוע את הגדרות ה-OIDC לפני שהם מפיצים אותן למפתחים. נוצר במרחב השמות kube-public |
הפעלת שירות הזהויות ל-GKE באשכול
כברירת מחדל, המערכת של ניהול הזהויות והרשאות הגישה (IAM) מוגדרת כספק הזהויות לאימות באשכול. אם אתם רוצים להשתמש ב-OIDC עם ספקי זהויות של צד שלישי, אתם יכולים להפעיל את שירות הזהויות ל-GKE באשכולות חדשים או קיימים באמצעות Google Cloud CLI.
הפעלת Identity Service for GKE באשכול חדש
כדי ליצור אשכול שבו מופעל שירות הזהויות ל-GKE, מריצים את הפקודה הבאה:
gcloud container clusters create CLUSTER_NAME \
--enable-identity-service
מחליפים את CLUSTER_NAME בשם של האשכול החדש.
הפעלת שירות הזהויות ל-GKE באשכול קיים
כדי להפעיל את שירות הזהויות ל-GKE באשכול קיים, מריצים את הפקודה הבאה:
gcloud container clusters update CLUSTER_NAME \
--enable-identity-service
מחליפים את CLUSTER_NAME בשם האשכול.
הגדרת שירות זהות ל-GKE
כדי להגדיר את הפרמטרים של שירות הזהויות ל-GKE, צריך להוריד את ClientConfig של default ולשנות אותו.
מורידים את ClientConfig של
default:kubectl get clientconfig default -n kube-public -o yaml > client-config.yamlמעדכנים את הקטע
spec.authenticationבהגדרות הרצויות:apiVersion: authentication.gke.io/v2alpha1 kind: ClientConfig metadata: name: default namespace: kube-public spec: name: cluster-name server: https://192.168.0.1:6443 authentication: - name: oidc oidc: clientID: CLIENT_ID certificateAuthorityData: OIDC_PROVIDER_CERTIFICATE extraParams: EXTRA_PARAMS issuerURI: ISSUER_URI cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc kubectlRedirectURI: KUBECTL_REDIRECT_URL scopes: SCOPES userClaim: USER groupsClaim: GROUPS userPrefix: USER_PREFIX groupPrefix: GROUP_PREFIXמחליפים את מה שכתוב בשדות הבאים:
-
CLIENT_ID: המזהה של אפליקציית הלקוח ששולחת בקשות אימות לספק ה-OIDC. -
OIDC_PROVIDER_CERTIFICATE: (אופציונלי) אישור PEM לספק ה-OIDC. השדה הזה יכול להיות שימושי אם ספק ה-OIDC משתמש באישורים בחתימה עצמית. כברירת מחדל, שירות הזהויות של GKE כולל קבוצה של שורשי CA ציבוריים. -
EXTRA_PARAMS: פרמטרים נוספים של מפתח/ערך שצריך לשלוח לספק ה-OIDC.- כדי לתת הרשאות לקבוצות, משתמשים ב-
resource=token-groups-claim. - כדי לאמת את Microsoft Azure ו-Okta, צריך להשתמש ב-
prompt=consent. - ב-Cloud Identity, משתמשים ב-
prompt=consent,access_type=offline.
- כדי לתת הרשאות לקבוצות, משתמשים ב-
-
ISSUER_URI: כתובת ה-URL שאליה נשלחות בקשות ההרשאה של OIDC, כמוhttps://example.com/adfs. שרת ה-API של Kubernetes משתמש בכתובת ה-URL הזו כדי לגלות מפתחות ציבוריים לאימות אסימונים. ה-URI חייב להשתמש ב-HTTPS. ב-Cloud Identity, משתמשים ב-https://accounts.google.com. -
KUBECTL_REDIRECT_URL: כתובת ה-URL להפניה אוטומטית שמשמשת אתkubectl oidc loginלצורך הרשאה. בדרך כלל הפורמט הואhttp://localhost:PORT/callback, כאשרPORTהוא כל יציאה שגדולה מ-1024שתהיה זמינה בתחנות העבודה של המפתחים, לדוגמהhttp://localhost:10000/callback. אתם צריכים לרשום את כתובת ה-URL אצל ספק ה-OIDC ככתובת URL מורשית להפניה אוטומטית של אפליקציית הלקוח. אם אתם משתמשים ב-Google Identity כספק ה-OIDC, קראו את המאמר הגדרת URI להפניה אוטומטית כדי לקבל הוראות. -
SCOPES: היקפי ההרשאות הנוספים שצריך לשלוח לספק ה-OIDC.- ב-Microsoft Azure וב-Okta נדרש ההיקף
offline_access. - ב-Cloud Identity, משתמשים ב-
openid, emailכדי לקבל אסימוני מזהה שמכילים את כתובת האימייל בטענת הנכוֹנוּת (claim) שלemail.
- ב-Microsoft Azure וב-Okta נדרש ההיקף
-
USER: הצהרת המשתמש מאסימון הזהות. -
GROUPS: טענת הנכוֹנוּת (claim) של הקבוצה מאסימון הזהות. -
USER_PREFIX: קידומת שנוספת לתביעות המשתמש כדי למנוע התנגשויות עם שמות קיימים. כברירת מחדל, תחילית של מנפיק מצורפת ל-userIDשניתן לשרת ה-API של Kubernetes (אלא אם הצהרת המשתמש היאemail). מזהה המשתמש שמתקבל הואISSUER_URI#USER. מומלץ להשתמש בקידומת, אבל אפשר להשבית אותה על ידי הגדרתUSER_PREFIXל--. -
GROUP_PREFIX: קידומת שנוספת לתחילת ההצהרות של הקבוצה כדי למנוע התנגשויות עם שמות קיימים. לדוגמה, אם יש שתי קבוצות בשםfoobar, מוסיפים את הקידומתgid-. הקבוצה שנוצרה היאgid-foobar.
-
מחילים את ההגדרה המעודכנת:
kubectl apply -f client-config.yamlאחרי שמחילים את ההגדרה הזו, שירות הזהויות ל-GKE פועל בתוך האשכול ומטפל בבקשות שמאחורי מאזן העומסים
gke-oidc-envoy. כתובת ה-IP בשדהspec.serverצריכה להיות כתובת ה-IP של מאזן העומסים. אם משנים את השדהspec.server, יכול להיות שפקודותkubectlייכשלו.יוצרים עותק של קובץ התצורה
client-config.yaml:cp client-config.yaml login-config.yamlמעדכנים את קובץ התצורה
login-config.yamlבאמצעות ההגדרהclientSecretבקטעspec.authentication.oidc.clientSecret: CLIENT_SECRETמחליפים את הערך
CLIENT_SECRETבסוד המשותף בין אפליקציית הלקוח של OIDC לבין ספק ה-OIDC.מפיצים את קובץ
login-config.yamlהמעודכן למפתחים.
הגדרת שירות הזהויות של GKE באשכולות עם כללי מדיניות מחמירים
כדי להגדיר את שירות הזהויות ל-GKE כך שיפעל כצפוי באשכולות עם מדיניות רשת ב-Kubernetes מחמירה, מבצעים את הפעולות הבאות:
- מוסיפים כלל של חומת אש ליציאת TCP
15000כדי לאפשר למישור הבקרה לתקשר עם ה-validating webhook שלClientConfig. - אם
gke-oidc-envoyנוצר כמאזן עומסים פנימי, צריך לחשוף אותו ב-VPC. - אם יש לכם כללי מדיניות שמונעים תעבורת נתונים בתוך האשכול, הוסיפו כלל חומת אש ליציאת TCP
8443כדי לאפשר לפריסה שלgke-oidc-envoyלתקשר עם הפריסה שלgke-oidc-service.
בגרסה 0.2.20 ואילך של רכיב שירות הזהויות ל-GKE לא נעשה שימוש ביציאת TCP 15000. אם גרסת הרכיב היא 0.2.20 ואילך, לא צריך להוסיף כלל חומת אש ליציאה 15000. כדי לבדוק את גרסת הרכיב, מריצים את הפקודה הבאה:
kubectl describe deployment gke-oidc-envoy -n anthos-identity-service \
| grep "components.gke.io/component-name: gke-oidc" -A1
הוספת מאפיינים מותאמים אישית למאזן העומסים
אחרי שמגדירים את שירות הזהויות ל-GKE, אפשר להוסיף הערות ומאפיינים בהתאמה אישית, כמו כתובת IP סטטית, למאזן העומסים gke-oidc-envoy. כדי לערוך את השירות gke-oidc-envoy, מריצים את הפקודה הבאה:
kubectl edit service gke-oidc-envoy -n anthos-identity-service
למידע נוסף על הגדרת איזון עומסים ב-TCP/UDP ל-GKE, עיינו במאמר פרמטרים של שירות LoadBalancer.
יצירת מדיניות RBAC לאשכול
אדמינים יכולים להשתמש בבקרת גישה מבוססת-תפקידים (RBAC) של Kubernetes כדי לתת גישה למשתמשים מאומתים באשכול. כדי להגדיר RBAC לאשכול, צריך להקצות תפקידי RBAC לכל מפתח. כדי לתת גישה למשאבים במרחב שמות מסוים, יוצרים Role ו-RoleBinding. כדי לתת גישה למשאבים באשכול שלם, יוצרים ClusterRole ו-ClusterRoleBinding.
לדוגמה, נניח שמשתמש צריך להציג את כל האובייקטים מסוג Secret באשכול. בשלבים הבאים מוסבר איך להקצות למשתמש את תפקידי ה-RBAC הנדרשים.
שומרים את המניפסט הבא של ClusterRole בתור
secret-viewer-cluster-role.yaml. מי שמקבל את התפקיד הזה יכול לקבל, לצפות ולפרט כל סוד באשכול.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-viewer rules: - apiGroups: [""] # The resource type for which access is granted resources: ["secrets"] # The permissions granted by the ClusterRole verbs: ["get", "watch", "list"]מחילים את המניפסט של ClusterRole:
kubectl apply -f secret-viewer-cluster-role.yamlשומרים את המניפסט הבא של ClusterRoleBinding בתור
secret-viewer-cluster-role-binding.yaml. הקישור מקצה את התפקידsecret-viewerלשם משתמש שמוגדר בקובץ התצורה של הלקוח.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: people-who-view-secrets subjects: - kind: User name: ISSUER_URI#USER apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-viewer apiGroup: rbac.authorization.k8s.ioמחליפים את מה שכתוב בשדות הבאים:
-
ISSUER_URI: ה-URI של המנפיק מ-spec.authentication.oidc.issuerURIבקובץ התצורה של הלקוח. -
USER: מזהה המשתמש בטוקן, בשם ההצהרה שהוגדר ב-spec.authentication.oidc.userClaimבקובץ התצורה של הלקוח.
-
מחילים את המניפסט של ClusterRoleBinding:
kubectl apply -f secret-viewer-cluster-role-binding.yaml
כניסה לאשכול ואימות שלו
כמפתחים שמקבלים את קובץ התצורה של OIDC מהאדמין, אתם יכולים לאמת את האשכולות שלכם.
מורידים את הקובץ
login-config.yamlשקיבלתם מהאדמין.מתקינים את ה-SDK של Google Cloud CLI, שמציע רכיב OIDC נפרד. כדי להתקין את זה, מריצים את הפקודה הבאה:
gcloud components install kubectl-oidcמאמתים את האשכול:
kubectl oidc login --cluster=CLUSTER_NAME --login-config=login-config.yamlנפתח דפדפן אינטרנט כדי להשלים את תהליך האימות.
אחרי האימות, אפשר להריץ פקודות של
kubectl, לדוגמה:kubectl get pods
השבתת שירות זהות עבור GKE
אפשר להשבית את שירות הזהויות ל-GKE באמצעות ה-CLI של gcloud. כדי להשבית את Identity Service for GKE, מריצים את הפקודה הבאה:
gcloud container clusters update CLUSTER_NAME \
--no-enable-identity-service
מגבלות ידועות
לרכיב gke-oidc-envoy, שאחראי לאימות באשכול באמצעות שירות הזהויות של GKE, יש מספר קבוע של רפליקות. כלומר, הוא לא משתנה באופן אוטומטי כדי להתמודד עם עלייה בתנועה. באשכולות אזוריים, הרכיב הזה נפרס עם שלוש רפליקות.
אי אפשר לשנות את קנה המידה של הפריסה של gke-oidc-envoy באופן ישיר. כדי ליהנות מפתרון חזק יותר שניתן להתאמה, מומלץ מאוד לעבור לאיחוד שירותי אימות הזהות של כוח עבודה.