המוצר שמתואר במסמכי התיעוד האלה, אשכולות Anthos ב-AWS (דור קודם), נמצא עכשיו במצב תחזוקה. כל ההתקנות החדשות צריכות להתבצע באמצעות המוצר מהדור הנוכחי, אשכולות Anthos ב-AWS.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

אימות באמצעות OpenID Connect ‏ (OIDC)

במאמר הזה מוסבר איך להגדיר את GKE ב-AWS לשימוש ב-OpenID Connect ‏(OIDC) לצורך אימות לאשכולות משתמשים. במאמר הזה מוסבר איך להגדיר GKE ב-AWS עם כל ספק OpenID.

כדי לשדרג אשכול שמשתמש באימות OIDC ל-Kubernetes 1.21, אפשר לעיין במאמר בנושא שדרוג לגרסה 1.21.

בסקירה הכללית על אימות תוכלו ללמוד על תהליך האימות ב-GKE ב-AWS.

סקירה כללית

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

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

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

פרסונות

הנושא הזה מתייחס לשלוש דמויות:

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

בחירת ספק OpenID

הקטע הזה מיועד לאדמינים בארגון.

אתם יכולים להשתמש בכל ספק OpenID שתבחרו. רשימה של ספקים מורשים זמינה בדף אישור OpenID.

יצירת כתובות URL להפניה אוטומטית

הקטע הזה מיועד לאדמינים בארגון.

ספק OpenID משתמש בכתובות URL להפניה מחדש כדי להחזיר אסימונים מזהים. צריך ליצור כתובות URL להפניה אוטומטית גם ל-CLI של gcloud וגם למסוףGoogle Cloud .

הגדרת כתובת ה-URL להפניה אוטומטית של ה-CLI של gcloud

כשמגדירים את ספק OpenID, מציינים את כתובת ה-URL להפניה אוטומטית של ה-CLI כ-http://localhost:PORT/callback

מחליפים את PORT במספר היציאה שגדול מ-1024.

הגדרת Google Cloud כתובת ה-URL להפניה אוטומטית של המסוף

כתובת ה-URL להפניה האוטומטית של מסוף Google Cloud היא:

https://console.cloud.google.com/kubernetes/oidc

כשמגדירים את הספק שתומך ב-OIDC, מציינים את כתובת ה-URL להפניה אוטומטית https://console.cloud.google.com/kubernetes/oidc.

רישום אפליקציות הלקוח אצל ספק OpenID

הקטע הזה מיועד לאדמינים בארגון.

כדי שהמפתחים יוכלו להשתמש ב-Google Cloud CLI או במסוף Google Cloud עם ספק OpenID, צריך לרשום את שני הלקוחות האלה אצל ספק OpenID. ההרשמה כוללת את השלבים הבאים:

מגלים מהו מזהה ה-URI של המנפיק של הספק. ה-CLI של gcloud אוGoogle Cloud המסוף שולחים בקשות אימות ל-URI הזה.
מגדירים את הספק עם כתובת ה-URL להפניה אוטומטית, כולל מספר היציאה, עבור ה-CLI של gcloud.
מגדירים את הספק עם כתובת ה-URL להפניה אוטומטית עבור Google Cloud המסוף, https://console.cloud.google.com/kubernetes/oidc.
יוצרים מזהה לקוח אחד שהספק משתמש בו כדי לזהות גם את Google Cloud CLI וגם את מסוףGoogle Cloud .
יוצרים סוד לקוח יחיד שמשמש את ה-CLI של gcloud ואת מסוף Google Cloud לאימות מול ספק OpenID.
יוצרים היקף מותאם אישית שבו ה-CLI של gcloud או מסוף Google Cloud יכולים להשתמש כדי לבקש את קבוצות האבטחה של המשתמש.
יוצרים שם טענה מותאם אישית שהספק משתמש בו כדי להחזיר את קבוצות האבטחה של המשתמש.

הגדרת האשכול

הקטע הזה מיועד לאדמינים של אשכולות.

כדי להגדיר אימות OIDC, צריך להגדיר את משאב ה-AWSCluster של אשכול המשתמשים עם פרטי האימות של האשכול. הפרטים מ-AWSCluster משמשים להגדרת OIDC גם עבור Google Cloud המסוף וגם עבור פלאגין האימות ל-GKE. ההגדרה כוללת את פרטי ה-OIDC הבאים:

authentication:
  awsIAM:
    adminIdentityARNs:
      - AWS_IAM_ARN
  oidc:
  -   certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET 
      extraParams:  EXTRA_PARAMS
      groupsClaim:  GROUPS_CLAIM
      groupPrefix:  GROUP_PREFIX
      issuerURI:  ISSUER_URI
      kubectlRedirectURI:  KUBECTL_REDIRECT_URI
      scopes:  SCOPES
      userClaim:  USER_CLAIM
      userPrefix:  USER_PREFIX

שדות אימות

בטבלה הבאה מתוארים השדות של אובייקט authentication.awsIAM.adminIdentityARNs.

בטבלה הבאה מתוארים השדות של אובייקט ה-`oidc`.

שדה	חובה	תיאור	פורמט
adminIdentityARNs	כן, אם מגדירים OIDC.	שם המשאב של אמזון (ARN) של הזהויות ב-AWS IAM (משתמשים או תפקידים) שקיבלו מ-GKE ב-AWS גישת אדמין לאשכול. לדוגמה: `arn:aws:iam::123456789012:group/Developers`	String

שדה	חובה	תיאור	פורמט
certificateAuthorityData	לא	אישור בקידוד PEM בקידוד Base64 של ספק OIDC. כדי ליצור את המחרוזת, מקודדים את האישור, כולל הכותרות, ל-Base64. כוללים את המחרוזת שמתקבלת ב-`certificateAuthorityData` כשורה אחת. דוגמה: `certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`	String
clientID	כן	מזהה של אפליקציית הלקוח ששולחת בקשות אימות לספק OpenID.	String
clientSecret	לא	סוד לשימוש עם טוקן צרכן בין אפליקציית לקוח OIDC לבין ספק OIDC.	String
extraParams	לא	פרמטרים נוספים של מפתח/ערך לשליחה לספק OpenID. אם אתם מאשרים קבוצה, צריך להעביר את `resource=token-groups-claim`. אם שרת ההרשאות מבקש הסכמה לאימות באמצעות Microsoft Azure ו-Okta, צריך להגדיר את `extraParams` ל-`prompt=consent`. ב-Cloud Identity, מגדירים את הערך `extraParams` ל-`prompt=consent,access_type=offline`.	רשימה מופרדת בפסיקים
groupsClaim	לא	הצהרת JWT שהספק משתמש בה כדי להחזיר את קבוצות האבטחה שלכם.	String
groupPrefix	לא	קידומת שנוספת לתביעות של קבוצות כדי למנוע התנגשויות עם שמות קיימים. לדוגמה, אם יש לכם שתי קבוצות בשם `foobar` add a prefix `gid-`, קבוצת התוצאה היא `gid-foobar`.	String
issuerURI	כן	כתובת ה-URL שאליה נשלחות בקשות הרשאה ל-OpenID, למשל `https://example.com/adfs`. שרת ה-API של Kubernetes משתמש בכתובת ה-URL הזו כדי לגלות מפתחות ציבוריים לאימות אסימונים. מזהה ה-URI חייב להשתמש ב-HTTPS.	מחרוזת כתובת URL
kubectlRedirectURI	כן	כתובת ה-URL להפניה אוטומטית שמשמשת את kubectl לאישור.	מחרוזת כתובת URL
היקפי הרשאות	כן	היקפי הרשאות נוספים לשליחה לספק OpenID. ‫Microsoft Azure ו-Okta דורשים את ההיקף `offline_access`.	רשימה מופרדת בפסיקים
userClaim	לא	הצהרת JWT לשימוש כשם המשתמש. אפשר לבחור טענות אחרות, כמו אימייל או שם, בהתאם לספק OpenID. עם זאת, לתלונות שאינן אימייל מתווספת קידומת של כתובת ה-URL של הגורם שהנפיק את התלונות כדי למנוע התנגשויות בשמות.	String
userPrefix	לא	תחילית שמוספת לתביעות של שמות משתמשים כדי למנוע התנגשויות עם שמות קיימים.	String

דוגמה: מתן הרשאה למשתמשים ולקבוצות

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

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

במקום להקצות מזהי משתמשים, מומלץ להשתמש במדיניות קבוצתית, שיכולה להיות גם קבועה וגם קלה יותר לבדיקה.

נניח שהספק שלכם יוצר אסימוני זהות שכוללים את השדות הבאים:

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

בהינתן פורמט האסימון הזה, כך מאכלסים את המפרט oidc בקובץ ההגדרות:

issuerURL: 'https://server.example.com'
username: 'sub'
usernamePrefix: 'uid-'
group: 'groupList'
groupPrefix: 'gid-'
extraParams: 'resource=token-groups-claim'
...

אחרי שיוצרים את אשכול המשתמשים, משתמשים בבקרת גישה מבוססת-תפקידים (RBAC) של Kubernetes כדי להעניק גישה עם הרשאות מיוחדות למשתמשים מאומתים.

בדוגמה הבאה, יוצרים ClusterRole שמעניק למשתמשים שלו גישת קריאה בלבד ל-Secrets של האשכול, ויוצרים משאב ClusterRoleBinding כדי לקשר את התפקיד לקבוצה המאומתת.

הגדרת ClusterRole. מעתיקים את קוד ה-YAML הבא לקובץ בשם secret-reader-role.yaml.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["secrets"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

הגדרת ClusterRoleBinding. מעתיקים את קוד ה-YAML הבא לקובץ בשם secret-reader-admins.yaml.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-admins
subjects:
  # Allows anyone in the "us-east1-cluster-admins" group to
  # read Secrets in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
  # Allows this specific user to read Secrets in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

החלת secret-reader-role.yaml ו-secret-reader-admins.yaml על האשכול באמצעות kubectl.
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f secret-reader-role.yaml && \
  kubectl apply -f secret-reader-admins.yaml
```
למשתמשים שקיבלו גישה ב-read-secrets-admins יש עכשיו גישת קריאה ל-Secrets באשכול שלכם.

יצירת הגדרות אישיות להתחברות

הקטע הזה מיועד לאדמינים של אשכולות.

אחרי שיוצרים אשכול משתמשים, צריך ליצור קובץ תצורה לאשכול באמצעות gcloud anthos create-login-config.

בספריית anthos-aws, משתמשים ב-anthos-gke כדי להחליף הקשר לאשכול המשתמשים.
‫
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
מחליפים את CLUSTER_NAME בשם אשכול המשתמש.
יוצרים את ההגדרה באמצעות gcloud anthos.
```
gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig
```
מחליפים את usercluster-kubeconfig בנתיב לקובץ kubeconfig של אשכול המשתמשים. ב-Linux וב-macOS, כברירת מחדל הקובץ הזה נמצא במיקום ~/.kube/config.

הפקודה הזו יוצרת קובץ (kubectl-anthos-config.yaml) שמכיל את פרטי ההגדרה שהמפתחים משתמשים בהם כדי לבצע אימות לאשכול באמצעות ה-CLI של gcloud. אין לשנות את הקובץ הזה.

למידע נוסף על התוכן של kubectl-anthos-config.yaml, אפשר לעיין בנספח.

מפיצים את קובץ התצורה למשתמשים שצריכים לבצע אימות לאשכולות המשתמשים. אפשר להפיץ את ההגדרה באמצעות:

הצבת הקובץ בספריית ברירת המחדל.
הפצת הקובץ בצורה מאובטחת.
הקובץ מאוחסן בשרת HTTPS.

ספריות ברירת מחדל של הגדרות כניסה

מיקומי ברירת המחדל לאחסון קובץ התצורה לכל מערכת הפעלה הם:

Linux: $HOME/.config/google/anthos/kubectl-anthos-config.yaml, כאשר $HOME הוא ספריית הבית של המשתמש.
macOS: $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml, כאשר ‫$HOME הוא ספריית הבית של המשתמש.
Windows: %APPDATA%/google/anthos/kubectl-anthos-config.yaml, כאשר %APPDATA% הוא ספריית נתוני האפליקציה של המשתמש.

אחרי שמפיצים את הגדרת הכניסה, המפתחים יכולים להגדיר את ה-CLI של gcloud כדי לגשת לאשכול.

שינוי האשכול אחרי שדרוג ל-Kubernetes 1.21

אחרי שמשדרגים את האשכול ל-Kubernetes 1.21, צריך להגדיר את GKE Identity Service ולהסיר את פרטי OIDC מההגדרה של האשכול. כדי לעדכן את ההגדרה, פועלים לפי השלבים הבאים:

פועלים לפי השלבים במאמר שדרוג האשכול.
בספריית anthos-aws, משתמשים ב-anthos-gke כדי להחליף הקשר לאשכול המשתמשים.
‫
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
מחליפים את CLUSTER_NAME בשם אשכול המשתמש.
פותחים את קובץ המניפסט שמכיל את AWSCluster בכלי לעריכת טקסט. משאירים את הקובץ פתוח ומשתמשים בערכים של האובייקט oidc כדי לבצע את השלבים במאמר הגדרת אשכולות ל-GKE Identity Service.
בספרייה של anthos-aws, משתמשים ב-anthos-gke כדי להעביר את ההקשר לשירות הניהול.
```
cd anthos-aws
anthos-gke aws management get-credentials
```
הערה: anthos-gke משתמש בהרשאות שציינתם כשביצעתם את הפקודה aws configure.
פותחים בכלי לעריכת טקסט את קובץ ה-YAML שיצר את ה-AWSCluster. אם אין לכם קובץ YAML ראשוני, אתם יכולים להשתמש ב-kubectl edit.
עריכת YAML
אם פעלתם לפי ההוראות במאמר יצירת אשכול משתמשים, קובץ ה-YAML נקרא cluster-0.yaml. פותחים את הקובץ בכלי לעריכת טקסט.
kubectl edit
כדי להשתמש ב-kubectl edit כדי לערוך את ה-AWSCluster, מריצים את הפקודה הבאה:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-name
```
מחליפים את cluster-name ב-AWSCluster. לדוגמה, כדי לערוך את אשכול ברירת המחדל, cluster-0, מריצים את הפקודה הבאה:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-0
```
מוחקים את האובייקט oidc מהמניפסט של האשכול.
שומרים את הקובץ. אם אתם משתמשים ב-kubectl edit, השינויים יחולו אוטומטית על ידי kubectl. אם עורכים את קובץ ה-YAML, מריצים את הפקודה הבאה כדי להחיל אותו על שירות הניהול:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f cluster-0.yaml
```
שירות הניהול מעדכן את ה-AWSCluster.

הגדרת gcloud לגישה לאשכול

הקטע הזה מיועד למפתחים או לאדמינים של אשכולות.

דרישות מוקדמות

כדי להשלים את הקטע הזה, צריך לבצע את הפעולות הבאות:

הגדרת כניסה.
גרסה מעודכנת של ה-CLI של gcloud עם רכיבי anthos-auth.
```
gcloud components update
gcloud components install anthos-auth
```
מריצים את הפקודה הבאה כדי לוודא שה-CLI של gcloud הותקן בהצלחה. הפקודה אמורה להחזיר פרטים על הארגומנטים הנדרשים והאפשרויות הזמינות.
```
gcloud anthos auth
```

אימות לאשכול

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

באמצעות ה-CLI של gcloud במחשב המקומי.
באמצעות ה-CLI של gcloud במכונה מרוחקת באמצעות מנהרת SSH.
באמצעות Connect במסוף Google Cloud .

gcloud local

משתמשים ב-gcloud anthos auth login כדי לאמת את הזהות שלכם באשכול באמצעות הגדרת הכניסה.

אם מיקמתם את הגדרת הכניסה במיקום ברירת המחדל והגדרתם את שם האשכול, תוכלו להשתמש ב-gcloud anthos auth login ללא אפשרויות. אפשר גם להגדיר את האשכול, המשתמש ופרטי אימות אחרים באמצעות פרמטרים אופציונליים.

ברירת מחדל

gcloud anthos auth login --cluster CLUSTER_NAME

מחליפים את CLUSTER_NAME בשם קלאסטר שמוגדר במלואו. לדוגמה, projects/my-gcp-project/locations/global/memberships/cluster-0-0123456a.

פרמטרים אופציונליים

הפונקציה gcloud anthos auth login תומכת בפרמטרים האופציונליים הבאים:

gcloud anthos auth login --cluster CLUSTER_NAME \
--user USERNAME --login-config ANTHOS_CONFIG_YAML \
--login-config-cert LOGIN_CONFIG_CERT_PEM \
--kubeconfig=KUBECONFIG --dry-run

הפרמטרים מתוארים בטבלה הבאה.

פרמטר	תיאור
`cluster`	השם של האשכול שאליו רוצים להתחבר. ברירת המחדל היא האשכול בקובץ `kubectl-anthos-config.yaml`.
`user`	שם המשתמש של פרטי הכניסה ב-`kubeconfig`. ברירת המחדל היא `{cluster-name}-anthos-default-user`.
`login-config`	הנתיב לקובץ התצורה שנוצר על ידי מנהל האשכול עבור המפתח, או כתובת URL שבה מתארח הקובץ. ברירת המחדל היא `kubectl-anthos-config.yaml`.
`login-config-cert`	אם משתמשים בכתובת URL בשביל `login-config`, צריך לציין את הנתיב לקובץ אישור CA כדי ליצור חיבורי HTTPS.
`kubeconfig`	הנתיב לקובץ kubeconfig שמכיל טוקנים. ברירת המחדל היא $HOME/.kube/config`.
הרצת בדיקה	אפשר לבדוק את האפשרויות של שורת הפקודה בלי לשנות את ההגדרה או את האשכול.

הפקודה gcloud anthos login מפעילה דפדפן שמבקש מהמשתמש להתחבר באמצעות פרטי הכניסה שלו לארגון, מבצעת את החלפת פרטי הכניסה של OIDC ומקבלת את הטוקנים הרלוונטיים. ה-CLI של gcloud כותב את האסימונים לקובץ kubeconfig. ‫kubectl משתמש בקובץ הזה כדי לבצע אימות לאשכול המשתמשים.

כדי לוודא שהאימות הצליח, מריצים כל פקודה של kubectl עם קובץ kubeconfig:

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get nodes --kubeconfig my.kubeconfig

gcloud tunnel

אם רוצים לבצע אימות לאשכול משתמשים ממכונה מרוחקת, אפשר לבצע את האימות באמצעות מנהרת SSH. כדי להשתמש במנהרה, קובץ תצורת האימות צריך להיות במחשב המרוחק, וצריכה להיות לכם אפשרות להגיע לספק Open ID מהמחשב המקומי.

במחשב המקומי, מריצים את הפקודה הבאה:

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

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

‫USERNAME עם משתמש שיש לו גישת SSH למכונה המרוחקת.
‫REMOTE_MACHINE בשם המארח או בכתובת ה-IP של המחשב המרוחק.
‫LOCAL_PORT היא יציאה זמינה במחשב המקומי שמשמשת את ssh ליצירת מנהרה למחשב המרוחק.
‫REMOTE_PORT היא היציאה שהגדרתם לכתובת ה-URL להפניה אוטומטית של OIDC. מספר היציאה הוא חלק מהשדה kubectlRedirectURI בקובץ התצורה של האימות.

במעטפת SSH, מריצים את הפקודה הבאה כדי להתחיל את תהליך האימות:

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

מחליפים את AUTH_CONFIG_FILE בנתיב של קובץ התצורה של האימות במחשב המרוחק. ה-CLI של gcloud מריץ שרת אינטרנט במכונה המרוחקת.

במחשב המקומי, בדפדפן, עוברים לכתובת http://localhost:LOCAL_PORT/login ופועלים לפי תהליך הכניסה של OIDC.

לקובץ kubeconfig במחשב המרוחק יש עכשיו את האסימון לגישה לאשכול המשתמשים.

במעטפת ה-SSH, מוודאים שיש לכם גישה לאשכול המשתמשים:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

המסוף

אפשר לבצע אימות באמצעות Google Cloud המסוף, ולהתחיל את תהליך האימות מדף האשכולות של Kubernetes במסוף Google Cloud :

פותחים את המסוף Google Cloud :

כניסה לדף Kubernetes clusters
מחפשים את האשכול GKE on AWS ברשימה ולוחצים על Login (התחברות).
בוחרים באפשרות Authenticate with the Identity Provider configured for the cluster (אימות באמצעות ספק הזהויות שהוגדר עבור האשכול) ולוחצים על LOGIN (כניסה).

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

עדכון הגדרות OIDC

כדי לעדכן את הגדרות ה-OIDC באשכול, משתמשים בפקודה kubectl edit.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit clientconfigs -n kube-public default

הכלי kubectl טוען את משאב ClientConfig בעורך ברירת המחדל. כדי לעדכן את ההגדרה, שומרים את הקובץ. הכלי kubectl מעדכן את משאב ClientConfig באשכול.

מידע על התוכן של משאב ClientConfig

נספח: הגדרת התחברות לדוגמה

דוגמה ל-kubectl-anthos-config.yaml: הדוגמה הזו מופיעה כדי להבין את התוכן שלה. תמיד צריך ליצור את הקובץ באמצעות gcloud anthos create-login-config.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
 name: default
 namespace: kube-public
spec:
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_CONFIG
      clientSecret: CLIENT_SECRET
      extraParams: resource=k8s-group-claim,domain_hint=consumers
      certificateAuthorityData:   CERTIFICATE_STRING
      issuerURI: https://adfs.contoso.com/adfs
      kubectlRedirectURI: http://redirect.kubectl.com/
      scopes: allatclaim,group
      userClaim: "sub"
      groupsClaim: "groups"
    proxy: PROXY_URL #Optional
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  name: projects/my-project/locations/global/membership/cluster-0
  server: https://192.168.0.1:PORT
  preferredAuthentication: oidc

הסברים על תוכן השדות זמינים במאמר שדות אימות.

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

פריסת עומס העבודה הראשון ב-GKE ב-AWS.

אימות באמצעות OpenID Connect ‏ (OIDC) קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

סקירה כללית

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

פרסונות

בחירת ספק OpenID

יצירת כתובות URL להפניה אוטומטית

הגדרת כתובת ה-URL להפניה אוטומטית של ה-CLI של gcloud

הגדרת Google Cloud כתובת ה-URL להפניה אוטומטית של המסוף

רישום אפליקציות הלקוח אצל ספק OpenID

הגדרת האשכול

שדות אימות

דוגמה: מתן הרשאה למשתמשים ולקבוצות

יצירת הגדרות אישיות להתחברות

הפצת הגדרות ההתחברות

ספריות ברירת מחדל של הגדרות כניסה

שינוי האשכול אחרי שדרוג ל-Kubernetes 1.21

עריכת YAML

kubectl edit

הגדרת gcloud לגישה לאשכול

דרישות מוקדמות

אימות לאשכול

gcloud local

ברירת מחדל

פרמטרים אופציונליים

gcloud tunnel

המסוף

עדכון הגדרות OIDC

נספח: הגדרת התחברות לדוגמה

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

אימות באמצעות OpenID Connect ‏ (OIDC)