הגדרת ניהול אימות ברמת הצי

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

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

  1. מתקינים ומגדירים את Google Cloud CLI:

    1. התקינו את ה-CLI של Google Cloud.

    2. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

    3. כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

      gcloud init
    4. אחרי שתאתחלו את ה-CLI של gcloud, עדכנו אותו והתקינו את הרכיבים הנדרשים:

      gcloud components update
      gcloud components install kubectl
    5. ב-CLI של gcloud, בוחרים את הפרויקט המארח של ה-fleet:
      ‫
      gcloud config set project FLEET_HOST_PROJECT_ID
      מחליפים את FLEET_HOST_PROJECT_ID במזהה הפרויקט המארח של הצי.

  2. מפעילים את ממשקי ה-API הנדרשים:

    1. במסוף Google Cloud , נכנסים לדף לבחירת הפרויקט:

      כניסה לדף לבחירת הפרויקט

    2. בוחרים את פרויקט המארח של צי הרכבים.

    3. מפעילים את ממשקי ה-API של GKE Hub ו-Kubernetes Engine, אם יש כאלה שלא מופעלים.

      תפקידים שנדרשים להפעלת ממשקי API

      כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

      הפעלת ממשקי ה-API

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

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות להגדרת אשכולות ברמת ה-fleet, צריך לבקש מהאדמין להקצות לכם את התפקיד אדמין של Fleet (roles/gkehub.admin) ב-IAM בפרויקט המארח של ה-fleet. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

הפעלת התכונה של שירות זהויות ברמת הצי

התכונה 'שירות זהויות ברמת הצי' משתמשת בבקר כדי לנהל את ההגדרה בכל אחד מהאשכולות בצי. צריך להפעיל את התכונה ברמת ה-Fleet רק בפרויקט המארח של ה-Fleet.

כדי להפעיל את התכונה ברמת ה-fleet, בוחרים באחת מהאפשרויות הבאות:

המסוף

  1. נכנסים לדף GKE Identity Service במסוף Google Cloud .

    כניסה אל GKE Identity Service

  2. לוחצים על הפעלת שירות הזהויות.

gcloud

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

gcloud container fleet identity-service enable

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

כדי להגדיר את האשכולות, צריך לציין את הפרטים הבאים:

  • מידע על ספק הזהויות, כמו מזהה לקוח וסוד.
  • מידע על אסימוני האינטרנט מסוג JSON‏ (JWT) שספק הזהויות משתמש בהם לאימות.
  • היקפים או פרמטרים נוספים שייחודיים לספק הזהויות.

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

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

כדי להגדיר את האשכולות, פועלים לפי השלבים הבאים:

המסוף

  1. בוחרים את האשכולות שרוצים להגדיר:

    1. נכנסים לדף GKE Identity Service במסוף Google Cloud .

      כניסה אל Feature Manager

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

    3. לוחצים על עדכון ההגדרה. החלונית Edit Identity Service Clusters Config תיפתח.

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

  2. בקטע ספק זהויות חדש, מגדירים את פרטי הספק:

    OIDC

    1. כדי ליצור הגדרת OIDC חדשה, לוחצים על New Open ID Connect.
    2. בשדה Provider name, מציינים את השם שרוצים להשתמש בו כדי לזהות את ההגדרה הזו. בדרך כלל זה השם של ספק הזהויות. השם צריך להתחיל באות, ואחריה עד 39 אותיות קטנות, מספרים או מקפים, והוא לא יכול להסתיים במקף. אחרי שיוצרים הגדרה, אי אפשר לערוך את השם הזה.
    3. מציינים את מזהה הלקוח מספק הזהויות בשדה מזהה לקוח.
    4. בשדה Client Secret, מציינים את סוד הלקוח שצריך לשתף בין אפליקציית הלקוח לבין ספק הזהויות.
    5. בשדה כתובת ה-URL של המנפיק מציינים את ה-URI שבו מוגשות בקשות הרשאה לספק הזהויות.
    6. לוחצים על הבא כדי להגדיר את מאפייני ה-OIDC.

    Azure AD

    1. כדי ליצור הגדרה חדשה של Azure AD, בוחרים באפשרות New Azure Active Directory (ספריית Azure Active חדשה).
    2. בשדה שם הספק מציינים את השם שרוצים להשתמש בו כדי לזהות את ההגדרה הזו. בדרך כלל זה שם ספק הזהויות. השם צריך להתחיל באות, ואחריה יכולים להיות עד 39 תווים של אותיות קטנות, מספרים או מקפים. השם לא יכול להסתיים במקף. אחרי שיוצרים הגדרה, אי אפשר לערוך את השם הזה.
    3. מציינים את מזהה הלקוח מספק הזהויות בשדה מזהה לקוח.
    4. בשדה Client Secret, מציינים את סוד הלקוח שצריך לשתף בין אפליקציית הלקוח לבין ספק הזהויות.
    5. מציינים את הדייר שהוא חשבון Azure AD שצריך לאמת בדייר.
    6. לוחצים על הבא כדי להגדיר את המאפיינים של Azure AD.

    LDAP

    1. בוחרים באפשרות LDAP כדי ליצור הגדרת LDAP חדשה.
    2. בשדה שם הספק מציינים את השם שרוצים להשתמש בו כדי לזהות את ההגדרה הזו. בדרך כלל זה שם ספק הזהויות. השם צריך להתחיל באות, ואחריה עד 39 אותיות קטנות, מספרים או מקפים, והוא לא יכול להסתיים במקף. אי אפשר לערוך את השם הזה אחרי שיוצרים הגדרה.
    3. לוחצים על הבא.
    4. מציינים את שם המארח (חובה), את סוג החיבור ל-LDAP ואת אישור ה-CA של שרת ה-LDAP בקידוד Base64.
    5. לוחצים על הבא כדי להגדיר את השרת.
    6. מציינים את השם הייחודי של המשתמש, המסנן, מאפיין ההתחברות ומאפיין המזהה.
    7. לוחצים על הבא כדי להגדיר את פרטי המשתמש.
    8. אם בוחרים להשתמש בקבוצות, צריך לציין את השם הייחודי של הקבוצה, את המסנן ואת מאפיין המזהה.
    9. לוחצים על הבא כדי להגדיר את פרטי הקבוצה.
    10. מציינים את שם המשתמש והסיסמה של חשבון השירות.
    11. לוחצים על Done כדי להגדיר את השם של חשבון השירות.
  3. לוחצים על הבא. הקטע הגדרת מאפיינים נפתח.

  4. מגדירים את המאפיינים של ספק הזהויות. כדי לראות את המאפיינים של OIDC או Azure AD, בוחרים באחת מהאפשרויות הבאות:

    OIDC

    • ‫kubectl redirect URI: כתובת ה-URL להפניה אוטומטית והיציאה שמשמשות את ה-CLI של gcloud ומצוינות על ידי מנהל הפלטפורמה בזמן ההרשמה, בדרך כלל בפורמט http://localhost:PORT/callback.
    • רשות אישורים (אופציונלי): אם מנהל הפלטפורמה שלכם מספק מחרוזת אישור בקידוד PEM לספק הזהויות.
    • Group Claim (אופציונלי): טענת ה-JWT (שם השדה) שספק הזהויות משתמש בה כדי להחזיר את קבוצות האבטחה של החשבון.
    • קידומת קבוצה (אופציונלי): הקידומת שרוצים להוסיף לשמות של קבוצות האבטחה כדי למנוע התנגשויות עם שמות קיימים בכללי בקרת הגישה, אם יש לכם הגדרות לכמה ספקי זהויות (בדרך כלל שם הספק).
    • שרת proxy (אופציונלי): כתובת שרת ה-proxy שמשמשת להתחברות לספק הזהויות, אם רלוונטי. יכול להיות שתצטרכו להגדיר את זה אם, לדוגמה, האשכול שלכם נמצא ברשת פרטית וצריך להתחבר לספק זהויות ציבורי. לדוגמה: http://user:password@10.10.10.10:8888.
    • היקפים (אופציונלי): היקפים נוספים שספק הזהויות שלכם דורש. ב-Microsoft Azure וב-Okta נדרש ההיקף offline_access. כדי להוסיף עוד היקפים, לוחצים על Add scope.
    • User Claim (הצהרת משתמש) (אופציונלי): הצהרת ה-JWT (שם השדה) שספק הזהויות משתמש בה כדי לזהות חשבון. אם לא מציינים כאן ערך, האשכול משתמש ב-sub, שהוא טענת מזהה המשתמש שמשמשת ספקים רבים. אפשר לבחור הצהרות אחרות, כמו "אימייל" או "שם", בהתאם לספק ה-OpenID. לכל טענה שאינה 'אימייל' מתווספת קידומת של כתובת ה-URL של המנפיק כדי למנוע התנגשויות בשמות.
    • User Prefix (תוספת לשם המשתמש) (אופציונלי): התוספת שרוצים להוסיף לפני טענות המשתמש כדי למנוע התנגשויות עם שמות קיימים, אם לא רוצים להשתמש בתוספת שמוגדרת כברירת מחדל.
    • פרמטרים נוספים (אופציונלי): פרמטרים נוספים שנדרשים להגדרה, שצוינו כמפתח וערך. לוחצים על Add param כדי להוסיף עוד פרמטרים לפי הצורך.
    • הפעלת אסימון גישה (אופציונלי): אם האפשרות הזו מופעלת, היא מאפשרת תמיכה בקבוצות עבור ספקי OIDC כמו Okta.
    • פריסת Google Cloud פרוקסי של מסוף (אופציונלי): אם האפשרות הזו מופעלת, נפרס פרוקסי שמאפשר למסוף Google Cloud להתחבר לספק זהויות מקומי שלא נגיש לכולם באינטרנט.

    Azure AD

    • כתובת ה-URI להפניה אוטומטית של kubectl: כתובת ה-URL להפניה אוטומטית והיציאה שמשמשות את ה-CLI של gcloud, שצוינו על ידי מנהל הפלטפורמה בזמן הרישום, בדרך כלל בפורמט http://localhost:PORT/callback.
    • User Claim (הצהרת משתמש) (אופציונלי): הצהרת ה-JWT (שם השדה) שספק הזהויות משתמש בה כדי לזהות חשבון. אם לא מציינים כאן ערך, האשכול משתמש בערך בסדר 'email',‏ 'preferred_username' או 'sub' כדי לאחזר את פרטי המשתמש.
    • Proxy (אופציונלי): כתובת שרת ה-proxy לשימוש כדי להתחבר לספק הזהויות, אם רלוונטי. יכול להיות שתצטרכו להגדיר את זה אם, לדוגמה, האשכול נמצא ברשת פרטית וצריך להתחבר לספק זהויות ציבורי. לדוגמה: http://user:password@10.10.10.10:8888.
  5. לוחצים על סיום.

  6. אופציונלי: כדי להוסיף עוד ספקים להגדרה, לוחצים על Add an identity provider וחוזרים על השלבים הקודמים.

  7. לוחצים על עדכון ההגדרה.

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

gcloud

כדי להגדיר את ה-fleet באמצעות ה-CLI של gcloud, יוצרים משאב בהתאמה אישית של Kubernetes בשם ClientConfig, עם שדות לכל המידע שהאשכול צריך כדי לקיים אינטראקציה עם ספק הזהויות. כדי ליצור ClientConfig ולהשתמש בו, פועלים לפי השלבים הבאים:

  1. יוצרים מפרט ClientConfig בקובץ בשם auth-config.yaml. כדי לראות דוגמאות להגדרות של OIDC,‏ SAML או LDAP, בוחרים באחת מהאפשרויות הבאות. הגדרות של ספקי זהויות אחרים מפורטות במאמר הגדרות ספציפיות לספק.

    OIDC

    בדוגמה הבאה של ClientConfig מוצגות גם הגדרות של oidc וגם הגדרות של azuread. מידע נוסף על המקרים שבהם כדאי להשתמש ב-oidc או ב-azuread זמין במאמר הגדרות ספציפיות לספק.

    apiVersion: authentication.gke.io/v2alpha1
    kind: ClientConfig
    metadata:
      name: default
      namespace: kube-public
    spec:
      authentication:
      - name: NAME
        proxy: PROXY_URL
        oidc:
          certificateAuthorityData: CERTIFICATE_STRING
          clientID: CLIENT_ID
          clientSecret: CLIENT_SECRET
          deployCloudConsoleProxy: PROXY_BOOLEAN
          extraParams: EXTRA_PARAMS
          groupsClaim: GROUPS_CLAIM
          groupPrefix: GROUP_PREFIX
          issuerURI: ISSUER_URI
          kubectlRedirectURI: http://localhost:PORT/callback
          scopes: SCOPES
          userClaim: USER_CLAIM
          userPrefix: USER_PREFIX
      - name: azure
        azureAD:
          clientID: CLIENT_ID
          clientSecret: CLIENT_SECRET
          tenant: TENANT_UUID
          kubectlRedirectURI: http://localhost:PORT/callback
          groupFormat: GROUP_FORMAT
          userClaim: USER_CLAIM
    

    למידע נוסף על השדות באובייקט oidc, קראו את המאמר שדות OIDC של ClientConfig.

    SAML

    הדוגמה הבאה של ClientConfig מציגה הגדרה של saml:

        apiVersion: authentication.gke.io/v2alpha1
        kind: ClientConfig
        metadata:
          name: default
          namespace: kube-public
        spec:
          authentication:
          - name: NAME
            saml:
              idpEntityID: ENTITY_ID
              idpSingleSignOnURI: SIGN_ON_URI
              idpCertificateDataList: IDP_CA_CERT
              userAttribute: USER_ATTRIBUTE
              groupsAttribute: GROUPS_ATTRIBUTE
              userPrefix: USER_PREFIX
              groupPrefix: GROUP_PREFIX
              attributeMapping:
                ATTRIBUTE_KEY_1 : ATTRIBUTE_CEL_EXPRESSION_1
                ATTRIBUTE_KEY_2 : ATTRIBUTE_CEL_EXPRESSION_2
            certificateAuthorityData: CERTIFICATE_STRING
            preferredAuthentication: PREFERRED_AUTHENTICATION
            server: <>
    

    למידע נוסף על השדות האלה, קראו את המאמר שדות SAML של ClientConfig.

    LDAP

    הדוגמה הבאה של ClientConfig מציגה הגדרה של ldap:

    apiVersion: authentication.gke.io/v2alpha1
    kind: ClientConfig
    metadata:
      name: default
      namespace: kube-public
    spec:
      authentication:
      - name: ldap
        ldap:
          server:
            host: HOST_NAME
            connectionType: CONNECTION_TYPE
            certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
          user:
            baseDn: BASE_DN
            loginAttribute: LOGIN_ATTRIBUTE
            filter: FILTER
            identifierAttribute: IDENTIFIER_ATTRIBUTE
          group:
            baseDn: BASE_DN
            filter: FILTER
            identifierAttribute: IDENTIFIER_ATTRIBUTE
          serviceAccount:
            simpleBindCredentials:
              dn: DISTINGUISHED_NAME
              password: PASSWORD
    

    מידע נוסף על השדות האלה זמין במאמר בנושא שדות LDAP של ClientConfig.

    אפשר להוסיף כמה הגדרות של ספקי זהויות לאותו ClientConfig. האשכול מנסה לבצע אימות בכל הגדרה לפי הסדר שבו הן מוגדרות, ומפסיק אחרי האימות הראשון שמתבצע בהצלחה.

  2. החלת ClientConfig על אשכול:

    gcloud container fleet identity-service apply \
        --membership=CLUSTER_NAME \
        --config=auth-config.yaml
    

    מחליפים את CLUSTER_NAME בשם הייחודי של האשכול בצי.

האשכול מתקין את כל הרכיבים הנדרשים ומשתמש ב-ClientConfig שיצרתם. הבקרה ברמת הצי מנהלת את ההגדרה של האשכול. כל שינוי מקומי בהגדרות האשכול מסונכרן על ידי בקר ההגדרות עם ההגדרות ברמת הצי.

בגרסאות מסוימות של אשכולות, הפעלת ההגדרה ברמת הצי מוסיפה כברירת מחדל גם הגדרה נוספת של authentication לאשכולות. כך האשכול יכול לאחזר מידע על קבוצות Google עבור חשבונות משתמשים שנכנסים באמצעות מזהה Google. ההגדרה הזו רלוונטית לאשכולות ב-Google Distributed Cloud (גם ב-VMware וגם ב-Bare Metal). למידע נוסף על התכונה "קבוצות Google", קראו את המאמר הגדרת שער Connect באמצעות קבוצות Google.

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

הגדרות ספציפיות לספק

בקטע הזה מובא מדריך להגדרת ספקי OIDC (כמו Azure AD ו-Okta), כולל הגדרת דוגמה שאפשר להעתיק ולערוך עם הפרטים שלכם.

Azure AD

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

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

...
spec:
  authentication:
  - name: oidc-azuread
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      extraParams: prompt=consent, access_type=offline
      issuerURI: https://login.microsoftonline.com/TENANT_ID/v2.0
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: openid,email,offline_access
      userClaim: email

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Azure AD (מתקדם)

ההגדרה האופציונלית הזו ל-Azure AD מאפשרת לאשכול לאחזר מידע על משתמשים וקבוצות ללא הגבלה על מספר הקבוצות לכל משתמש, באמצעות Microsoft Graph API. מידע על פלטפורמות שתומכות בהגדרה הזו זמין במאמר מידע על הגדרת ספק זהויות.

אם אתם צריכים לאחזר פחות מ-200 קבוצות לכל משתמש, מומלץ להשתמש בהגדרת ברירת המחדל באמצעות עוגן oidc ב-ClientConfig. מידע נוסף זמין בהוראות ל-Azure AD.

חובה למלא את כל השדות בהגדרת הדוגמה.

...
spec:
  authentication:
  - name: azure
    azureAD:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      tenant: TENANT_UUID
      kubectlRedirectURI: http://localhost:PORT/callback
      groupFormat: GROUP_FORMAT
      userClaim: USER_CLAIM

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

מחליפים את GROUP_FORMAT בפורמט שבו רוצים לאחזר את פרטי הקבוצה. השדה הזה יכול לקבל ערכים שמתאימים ל-ID או ל-NAME של קבוצות המשתמשים. ההגדרה הזו זמינה רק לאשכולות בפריסות של Google Distributed Cloud (on-premises).

Okta

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

...
spec:
  authentication:
  - name: okta
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      enableAccessToken: true
      extraParams: prompt=consent
      groupsClaim: groups
      issuerURI: https://OKTA_ISSUER_URI/
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: offline_access,email,profile,groups
      userClaim: email

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

הגדרת ברירות מחדל ברמת ה-fleet

אתם יכולים לציין הגדרת ברירת מחדל לאימות ברמת הצי. בהגדרה הזו, כל אשכול חדש שתרשמו ל-fleet ישתמש באופן אוטומטי בהגדרות האימות שציינתם.

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

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

כדי להגדיר תצורת ברירת מחדל ברמת הצי:

  1. יוצרים ClientConfig בקובץ בשם fleet-default.yaml. מידע נוסף על יצירת הקובץ זמין בשלבים של ה-CLI של gcloud בקטע הגדרת אשכולות.
  2. כדי להחיל את הגדרות ברירת המחדל ברמת הצי, מריצים אחת מהפקודות הבאות:

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

      gcloud container fleet identity-service enable --fleet-default-member-config=fleet-default.yaml
    • אם התכונה של שירות הזהויות ברמת הארגון מופעלת, צריך להחיל את הגדרת ברירת המחדל החדשה ברמת הארגון:

      gcloud container fleet identity-service apply --fleet-default-member-config=default-config.yaml

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

  3. כדי להחיל את הגדרות ברירת המחדל על קלאסטר קיים של חבר ב-Fleet, מריצים את הפקודה הבאה:

    gcloud container fleet identity-service apply --origin=fleet --membership=CLUSTER_NAME

הסרת הגדרות ברירת המחדל ברמת הצי

כדי להסיר את הגדרת ברירת המחדל, מריצים את הפקודה הבאה:

gcloud container fleet identity-service delete --fleet-default-member-config

כשרושמים אשכולות חדשים לצי, הם לא משתמשים באופן אוטומטי בהגדרת אימות.

אימות ההגדרה של שירות הזהויות

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

המסוף

  1. נכנסים לדף Feature Manager במסוף Google Cloud .

    מעבר אל "ניהול תכונות"

    כל התכונות המופעלות מופיעות בחלונית שלהן עם הסטטוס מופעל.

  2. לוחצים על פרטים בחלונית שירות הזהויות. בחלונית הפרטים מוצג הסטטוס של האשכולות הרשומים.

gcloud

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

gcloud container fleet identity-service describe

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

אחרי שמגדירים את האשכולות, ממשיכים להגדרת גישת משתמשים.