שימוש בספקי זהויות חיצוניים לאימות ב-GKE

טייס אוטומטי רגילה

בדף הזה מוסבר איך להגדיר אימות לאשכולות של Google Kubernetes Engine ‏ (GKE) מספקי זהויות חיצוניים (IdPs).

הדף הזה מיועד לאדמינים ולמפעילים של פלטפורמות ולאדמינים של זהויות וחשבונות שמשתמשים ב-IdP חיצוני שתומך ב-OpenID Connect ‏ (OIDC) או ב-Security Assertion Markup Language ‏ (SAML) 2.0.

לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את המושגים הבאים שקשורים לאימות ול-OpenID:

שיטות אימות של ספקי IdP חיצוניים ב-GKE

מומלץ – איחוד שירותי אימות הזהות של כוח עבודה

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

לא מומלץ – שירות הזהויות ל-GKE

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

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

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

מפעילים את ממשק Google Kubernetes Engine API.

הפעלת Google Kubernetes Engine API

אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

לתשומת ליבכם

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

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

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

מגדירים איחוד זהויות של כוח עבודה בארגון וב-IdP חיצוני. הוראות מפורטות זמינות במאמר הגדרת איחוד שירותי אימות הזהות של כוח עבודה.
מגדירים גישה מה-IdP החיצוני אל Google Cloud המסוף של איחוד שירותי אימות הזהות של כוח העבודה. פרטים נוספים זמינים במאמר הגדרת גישת משתמשים למסוף (מאוחד).
מגדירים את גישת המשתמשים באמצעות אחד ממנגנוני ההרשאה הבאים:
- Kubernetes RBAC
- מדיניות הרשאות ב-IAM
כדי שהמשתמשים יוכלו לגשת לאשכולות, הם צריכים לפעול לפי השלבים הבאים:
1. כניסה ל-CLI של gcloud באמצעות זהות מאוחדת
2. מגדירים את kubectl לאימות לאשכול ספציפי על ידי הפעלת הפקודה gcloud container clusters get-credentials.

הגדרת גישת משתמשים לאשכולות באמצעות RBAC

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

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

זהויות מזהה של חשבון משתמש

משתמש יחיד

זהויות	מזהה של חשבון משתמש
משתמש יחיד	principal://iam.googleapis.com/locations/global/workforcePools/`WORKFORCE_IDENTITY_POOL`/subject/`SUBJECT_ATTRIBUTE_VALUE` מחליפים את מה שכתוב בשדות הבאים: ‫`WORKFORCE_IDENTITY_POOL`: השם של מאגר הזהויות של כוח העבודה. `SUBJECT_ATTRIBUTE_VALUE`: הערך של מאפיין בהצהרת הנושא של אסימון הזהות. לדוגמה, יכול להיות שזה הערך של השדה `NameID` בטענת נכוֹנוּת (assertion) של SAML 2.0. לדוגמה: 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` מחליפים את מה שכתוב בשדות הבאים: ‫`WORKFORCE_IDENTITY_POOL`: השם של מאגר הזהויות של כוח העבודה. ‫`GROUP_NAME`: השם של קבוצה שהמשתמש שמבצע את האימות חבר בה. באסימון ה-IdP צריך להיות מיפוי מאפיינים למאפיין Google Cloud `google.groups`. לדוגמה: principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/subject/SUBJECT_ATTRIBUTE_VALUE

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

‫WORKFORCE_IDENTITY_POOL: השם של מאגר הזהויות של כוח העבודה.
SUBJECT_ATTRIBUTE_VALUE: הערך של מאפיין בהצהרת הנושא של אסימון הזהות. לדוגמה, יכול להיות שזה הערך של השדה NameID בטענת נכוֹנוּת (assertion) של SAML 2.0.

לדוגמה:

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

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

‫WORKFORCE_IDENTITY_POOL: השם של מאגר הזהויות של כוח העבודה.
‫GROUP_NAME: השם של קבוצה שהמשתמש שמבצע את האימות חבר בה. באסימון ה-IdP צריך להיות מיפוי מאפיינים למאפיין Google Cloud google.groups.

לדוגמה:

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 קיימים, אתם צריכים לעבור לאיחוד שירותי אימות הזהויות של כוח העבודה. השיטות האלה משתמשות בתחבירים שונים כדי להתייחס לאותם עקרונות, כפי שמוצג בטבלה הבאה:

תחביר של Identity Service for GKE	תחביר של איחוד שירותי אימות הזהות של כוח העבודה
`amal@example.com`	`principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com`
`sre-group`	`principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre-group`

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

מגדירים איחוד זהויות של כוח עבודה בארגון וב-IdP חיצוני. הוראות מפורטות זמינות במאמר הגדרת איחוד שירותי אימות הזהות של כוח עבודה.
מעדכנים את קובצי המניפסט של כל RoleBinding ו-ClusterRoleBinding באשכולות כדי להשתמש בתחביר של מזהה איחוד שירותי אימות הזהות של כוח העבודה. אפשר לבחור באחת מהאפשרויות הבאות:
- עדכונים פרוגרמטיים: מתקינים ומריצים את כלי השירות gke-identity-service-migrator. הוראות מפורטות מופיעות בקובץ README של מאגר GoogleCloudPlatform/gke-utilities.
  
  הכלי הזה מוצא קשרי RBAC קיימים שמשתמשים בתחביר של שירות הזהויות ל-GKE, ויוצר מניפסטים חדשים שמשתמשים במזהים המתאימים של עקרונות איחוד שירותי אימות הזהות של כוח העבודה.
- עדכונים ידניים: לכל קשירה שמפנה למשתמש או לקבוצה מאומתים, צריך ליצור עותק נפרד של קובץ המניפסט של האובייקט שמשתמש בתחביר של מזהה איחוד הזהויות של כוח העבודה.
מחילים את המניפסטים המעודכנים של RoleBindings ו-ClusterRoleBindings על האשכול.
בודקים שהמשתמשים יכולים לגשת לאותם משאבים כשהם מבצעים אימות באמצעות איחוד שירותי אימות הזהות של כוח העבודה.
מסירים את הקישורים המיושנים של RBAC מהאשכול.
השבתה של Identity Service ל-GKE

שימוש בשירות זהויות ל-GKE

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

הפעלת שירות הזהויות ל-GKE באשכול.
הגדרת שירות הזהויות ל-GKE
יצירת מדיניות RBAC לאשכול.

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

אובייקטים של Kubernetes שנוצרו על ידי Identity Service for GKE

בטבלה הבאה מפורטים אובייקטים של Kubernetes שנוצרים כשמפעילים את שירות הזהויות ל-GKE באשכול:

אובייקטים של Kubernetes
`anthos-identity-service`	‫`Namespace` משמש לשירות הזהויות לפריסות GKE.
`kube-public`	`Namespace` משמש לקובץ התצורה של לקוח `default`.
`gke-oidc-envoy`	`LoadBalancer` נקודת הקצה (endpoint) לבקשות OIDC. חיצוני כברירת מחדל. אם נוצר באשכול ללא נקודת קצה של כתובת IP חיצונית, נקודת הקצה היא פנימית לענן הווירטואלי הפרטי של האשכול. נוצר במרחב השמות `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 של מאזן העומסים. נוצר במרחב השמות `anthos-identity-service`
`default`	‫`ClientConfig CRD` מכיל פרמטרים של OIDC כמו שיטת האימות המועדפת, הגדרת ספק הזהויות ומיפויים של טענות לגבי משתמשים וקבוצות. משמש לאימות של טוקן הזהות. משמש אדמינים של אשכולות כדי להגדיר את הגדרות OIDC לפני הפצה למפתחים. נוצר במרחב השמות `kube-public`

הפעלת שירות הזהויות ל-GKE באשכול

כברירת מחדל, ניהול הזהויות והרשאות הגישה (IAM) מוגדר כספק הזהויות לאימות של אשכולות. אם רוצים להשתמש ב-OIDC עם ספקי זהויות של צד שלישי, אפשר להפעיל את Identity Service ל-GKE באשכולות חדשים או קיימים באמצעות Google Cloud CLI.

הפעלת שירות הזהויות ל-GKE באשכול חדש

כדי ליצור אשכול עם Identity Service for 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, צריך להוריד ולשנות את הקובץ default ClientConfig.

מורידים את default ClientConfig:

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 כולל קבוצה של שורשים ציבוריים כברירת מחדל.
- ‫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 הזו כדי לגלות מפתחות ציבוריים לאימות אסימונים. חובה להשתמש ב-HTTPS ב-URI. ב-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 כדי לקבל אסימוני מזהה שמכילים את כתובת האימייל בטענת email.
- ‫USER: הצהרת המשתמש מאסימון הזהות.
- ‫GROUPS: הצהרת הקבוצה מאסימון הזהות.
- ‫USER_PREFIX: קידומת שנוספת לתביעות של משתמשים כדי למנוע התנגשויות עם שמות קיימים. כברירת מחדל, קידומת של המוסד המנפיק מצורפת ל-userID שמועבר לשרת Kubernetes API (אלא אם טענת המשתמש היא email). מזהה המשתמש שמתקבל הוא ISSUER_URI#USER. מומלץ להשתמש בקידומת, אבל אפשר להשבית את הקידומת על ידי הגדרת USER_PREFIX ל--.
- ‫GROUP_PREFIX: קידומת שנוספת לפני הצהרות של קבוצות כדי למנוע התנגשויות עם שמות קיימים. לדוגמה, אם יש לכם שתי קבוצות בשם foobar, מוסיפים את הקידומת gid-. הקבוצה שנוצרה היא gid-foobar.
החלת ההגדרות המעודכנות:
```
kubectl apply -f client-config.yaml
```
אחרי שמחילים את ההגדרה הזו, Identity Service for 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 באשכולות עם כללי מדיניות מחמירים

כדי להגדיר את Identity Service for GKE כך שיפעל כמצופה באשכולות שמוגדרת בהם מדיניות רשת מחמירה, מבצעים את הפעולות הבאות:

מוסיפים כלל לחומת האש ליציאת TCP‏ 15000 כדי לאפשר למישור הבקרה לתקשר עם ה-webhook של האימות ClientConfig.
אם gke-oidc-envoy נוצר כמאזן עומסים פנימי, צריך לחשוף אותו ב-VPC.
אם יש לכם מדיניות שמונעת תעבורה בתוך האשכול, צריך להוסיף כלל חומת אש ליציאת TCP‏ 8443 כדי לאפשר לפריסת gke-oidc-envoy לתקשר עם פריסת gke-oidc-service.

בגרסה 0.2.20 ואילך של רכיב Identity Service for 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 לכל מפתח. כדי להעניק גישה למשאבים במרחב שמות מסוים, יוצרים תפקיד וRoleBinding. כדי להעניק גישה למשאבים בכל האשכול, יוצרים ClusterRole ו-ClusterRoleBinding.

לדוגמה, נניח שיש משתמש שצריך להציג את כל אובייקטי הסודות באשכול. בשלבים הבאים מוקצים לתפקידי ה-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. כדי להשבית את שירות הזהויות ל-GKE, מריצים את הפקודה הבאה:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-identity-service

מגבלות ידועות

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

אי אפשר לשנות את גודל הפריסה של gke-oidc-envoy באופן ישיר. מומלץ מאוד לעבור לאיחוד שירותי אימות הזהות של כוח עבודה כדי לקבל פתרון חזק יותר וניתן להרחבה.

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

שיטות אימות של ספקי IdP חיצוניים ב-GKE

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

לתשומת ליבכם

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

הגדרת גישת משתמשים לאשכולות באמצעות RBAC

כניסה ואימות לאשכול

העברת אשכולות של Identity Service ל-GKE אל איחוד שירותי אימות הזהות של כוח העבודה

שימוש בשירות זהויות ל-GKE

אובייקטים של Kubernetes שנוצרו על ידי Identity Service for GKE

הפעלת שירות הזהויות ל-GKE באשכול

הפעלת שירות הזהויות ל-GKE באשכול חדש

הפעלת שירות הזהויות ל-GKE באשכול קיים

הגדרת שירות הזהויות ל-GKE

הגדרת שירות הזהויות ל-GKE באשכולות עם כללי מדיניות מחמירים

הוספת מאפיינים מותאמים אישית למאזן העומסים

יצירת מדיניות RBAC לאשכול

כניסה ואימות לאשכול

השבתה של שירות הזהויות ל-GKE

מגבלות ידועות

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

שימוש בספקי זהויות חיצוניים לאימות ב-GKE