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

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

מגבלות

חובה להשתמש בסוג אשכול שתומך ב-SAML.

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

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

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

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

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

    gcloud components update
    gcloud components install kubectl
  5. חשוב לוודא שאדמין הפלטפורמה סיפק לכם את כל המידע שאתם צריכים על הספק. מידע נוסף זמין במאמר בנושא שיתוף פרטים של ספק.

הגדרת האשכול

כדי להגדיר אשכול לאימות באמצעות SAML, צריך להגדיר משאב בהתאמה אישית של Kubernetes בשם ClientConfig עם מידע על ספק הזהויות והפרמטרים שהספק צריך להחזיר כדי לקבל מידע על המשתמש.

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

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

מחליפים את KUBECONFIG_PATH בנתיב לקובץ kubeconfig של האשכול, לדוגמה $HOME/.kube/config.

כלי לעריכת טקסט טוען את משאב ClientConfig של האשכול. מוסיפים את האובייקט spec.authentication.saml כמו בדוגמה הבאה. אסור לשנות נתוני ברירת מחדל שכבר נכתבו.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: NAME
    saml:
      attributeMapping:
        ATTRIBUTE_KEY_1: ATTRIBUTE_CEL_EXPRESSION_1
        ATTRIBUTE_KEY_2: ATTRIBUTE_CEL_EXPRESSION_2
      groupsAttribute: GROUPS_ATTRIBUTE
      groupPrefix: GROUP_PREFIX
      idpEntityID: ENTITY_ID
      idpSingleSignOnURI: SIGN_ON_URI
      idpCertificateDataList: IDP_CA_CERT
      userAttribute: USER_ATTRIBUTE
      userPrefix: USER_PREFIX
    certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
    preferredAuthentication: PREFERRED_AUTHENTICATION
    server: <>
# Rest of the resource is managed by Google. DO NOT MODIFY.
...

אפשר להוסיף כמה הגדרות של ספקי זהויות OIDC,‏ LDAP ו-SAML לאותו ClientConfig. האשכול מנסה לבצע אימות באמצעות כל הגדרה לפי הסדר שבו הן מוגדרות, ומפסיק אחרי האימות המוצלח הראשון. בדוגמה הבאה של ClientConfig מוגדרים כמה ספקי זהויות בסדר מסוים:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - aws:
      region: us-west-2
    name: AWS Login
  - ldap:
  # Multiple lines are omitted here.
  - saml:
  # Multiple lines are omitted here.
  - azureAD:
  # Multiple lines are omitted here.
  - oidc:
    name: Okta OIDC
  # Multiple lines are omitted here.
  - oidc:
    name: Google OIDC
  # Multiple lines are omitted here.

שדות SAML ב-ClientConfig

בטבלה הבאה מתוארים השדות של אובייקט ClientConfig saml. השדות שצריך להוסיף תלויים בטוקנים של ספק הזהויות ובאופן שבו האדמין של הפלטפורמה הגדיר את הספק.

שדה חובה תיאור פורמט
name כן השם שרוצים להשתמש בו כדי לזהות את ההגדרה הזו, בדרך כלל שם ספק הזהויות. שם ההגדרה צריך להתחיל באות, להמשיך בעד 39 אותיות קטנות, מספרים או מקפים, ולא להסתיים במקף. String
idpEntityID כן מזהה הישות ב-SAML של ספק ה-SAML, שמוגדר בפורמט URI. לדוגמה: https://www.idp.com/saml. מחרוזת כתובת URL
idpSingleSignOnURI כן נקודת הקצה של ספק SAML ל-SSO, שצוינה בפורמט URI. לדוגמה: https://www.idp.com/saml/sso. מחרוזת כתובת URL
idpCertificateDataList כן תואם לאישורים של ספק הזהויות שמשמשים לאימות תגובת SAML. האישורים האלה צריכים להיות בקידוד Base64 רגיל ובפורמט PEM. כדי לאפשר עדכון של אישורים של ספקי זהויות, יש תמיכה בעד שני אישורים לכל היותר. String
userAttribute לא השם של המאפיין בתגובת SAML שמכיל את שם המשתמש. String
groupsAttribute לא השם של המאפיין בתגובת SAML שמכיל את פרטי הקבוצה של המשתמש. String
userPrefix לא התחילית שרוצים להוסיף לתביעות של משתמשים כדי למנוע התנגשויות עם שמות קיימים, אם לא רוצים להשתמש בתחילית שמוגדרת כברירת מחדל. String
groupPrefix לא הקידומת שרוצים להוסיף לשמות של קבוצות אבטחה. הסיבה לכך היא כדי למנוע התנגשויות עם שמות קיימים בכללי בקרת הגישה, אם יש לכם הגדרות לכמה ספקי זהויות (בדרך כלל שם הספק). String
attributeMapping לא מיפוי של מאפייני משתמש נוספים. String
certificateAuthorityData לא אם מנהל הפלטפורמה שלכם מספק לכם מחרוזת של אישור בקידוד PEM, זהו ספק הזהויות. מוסיפים את המחרוזת שמתקבלת ל-certificateAuthorityData כשורה אחת. String
preferredAuthentication לא השם של שיטת האימות המועדפת שהוגדרה באשכול. String

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

מה השלב הבא?

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