שילוב תמיכה במשתמשי Active Directory ב-Kubernetes

בחירת גרסה של מאמר העזרה:

במאמר הזה מוסבר איך להפעיל שילוב של Active Directory באשכול מסדי נתונים של AlloyDB Omni מבוסס-Kubernetes, כדי לאפשר למשתמשים קיימים מבוססי-Active Directory לגשת למסד הנתונים של AlloyDB Omni. שילוב עם Active Directory מספק הרשאה באמצעות GSSAPI למשתמשים שאומתו באמצעות מנגנון Kerberos כדי לגשת ל-AlloyDB Omni.

מידע נוסף זמין במאמר בנושא סקירה כללית על Active Directory.

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

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

כדי להפעיל את השילוב עם Active Directory, צריך:

  • אשכול AlloyDB Omni שנפרס בסביבת Kubernetes
  • קובץ keytab של שרת Active Directory

העברה מאופרטור AlloyDB Omni Kubernetes מגרסה 1.4.0 לגרסה 1.5.0

אם אתם משתמשים בשילוב Active Directory באופרטור AlloyDB Omni בגרסה 1.4.0 או בגרסה קודמת, אתם צריכים לעבור לגרסה 1.5.0 של אופרטור AlloyDB Omni.

כדי לבצע מיגרציה לגרסה 1.5.0 של אופרטור AlloyDB Omni, פועלים לפי השלבים הבאים:

  1. שדרוג האופרטור AlloyDB Omni לגרסה 1.5.0
  2. יוצרים משאב אימות שמוגדר על ידי המשתמש.
    1. יוצרים מניפסט חדש של משאב UserDefinedAuthentication.
    2. מאכלסים את spec.dbclusterRef בשם של DBCluster היעד.
    3. מאכלסים את spec.keytabSecretRef בשם של סוד keytab.
    4. מעתיקים את כללי pg_hba.conf הקיימים שרלוונטיים לאימות של Active Directory ו-Kerberos לשדה spec.pgHbaEntries.
    5. מעתיקים את pg_ident.conf rules הקיים (אם יש כזה) לשדה spec.pgIdentEntries.
    6. מחילים את המניפסט החדש, לדוגמה, kubectl apply -f user-auth-crd.yaml.
  3. מסירים את הגדרת התצוגה המקדימה ומבצעים פריסה מחדש של האשכול.
    1. בהגדרת המשאב DBCluster, מסירים את כל ההערות ששימשו בעבר להגדרת השילוב עם Active Directory, למשל, כללי אימות מבוסס-מארח (HBA), כללי ident והערה של קובץ keytab.
    2. מוחקים את מפות התצורה pg_hba ו-pg_ident שיצרתם.
    3. מחילים מחדש את המניפסט המעודכן של DBCluster.

הגדרת תמיכה ב-Active Directory

  1. יוצרים ומחילים סוד עם קובץ ה-keytab:

    apiVersion: v1
kind: Secret
metadata:
  name: KEYTAB_SECRET_NAME
  namespace: DB_CLUSTER_NAMESPACE
type: Opaque
data:
  krb5.keytab: |
   KEYTAB_FILE_CONTENT

    הנה דוגמה לפקודה שיוצרת קובץ keytab בשרת Active Directory:

    ktpass /princ postgres/DBCLUSTER_HOST@REALM /Pass PASSWORD /mapuser postgres /crypto ALL /ptype KRB5_NT_Principal /out OUTPUT_PATH

    ‫ALLOYDB_HOST הוא המארח שמפנה אל DBCluster או אל כתובת ה-IP של DBCluster.

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

    apiVersion: alloydbomni.dbadmin.goog/v1
kind: UserDefinedAuthentication
metadata:
  name: USER_DEFINED_AUTHENTICATION_NAME
  namespace: DB_CLUSTER_NAMESPACE
spec:
  dbclusterRef:
    name: DB_CLUSTER_NAME
  keytabSecretRef:
    name: KEYTAB_SECRET_NAME
  pgHbaEntries:
    PG_HBA_ENTRIES
  pgIdentEntries:
    PG_IDENT_ENTRIES

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

    • ‫USER_DEFINED_AUTHENTICATION_NAME: השם של UserDefinedConfiguration, לדוגמה, DB_CLUSTER_NAME-ad-auth.
    • ‫DB_CLUSTER_NAMESPACE: מרחב השמות של Kubernetes לתוכנית הגיבוי הזו. מרחב השמות חייב להיות זהה למרחב השמות של אשכול מסד הנתונים.
    • ‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים שהקציתם לו כשיצרתם אותו.
    • ‫KEYTAB_SECRET_NAME: השם של קובץ ה-keytab שיצרתם.

    • PG_HBA_ENTRIES: pg_hba.conf רשומות כמחרוזת של רשימה. הערכים האלה מחליפים את ערכי ברירת המחדל ב-pg_hba.conf. אם מוסיפים הגדרה לא תקינה, המשתמשים לא יכולים להיכנס לחשבון.

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

      מידע נוסף זמין במאמר בנושא קובץ pg_hba.conf.

    • PG_IDENT_ENTRIES: pg_ident.conf רשומות כמחרוזת של רשימה. כדי להטמיע מיפוי של שמות משתמשים, מציינים map= בשדה האפשרויות בקובץ pg_hba.conf. מידע נוסף זמין במאמר בנושא מפות של זהויות.

      מקרה לדוגמה:

       apiVersion: v1
 kind: Secret
 metadata:
   name: db-keytab-dbcluster-sample
 type: Opaque
 data:
   krb5.keytab: |
     DUMMY_KEYTAB
 ---
 apiVersion: alloydbomni.dbadmin.goog/v1
 kind: UserDefinedAuthentication
 metadata:
   name: dbcluster-sample-ad-auth
 spec:
   dbclusterRef:
     name: dbcluster-sample
   keytabSecretRef:
     name: db-keytab-dbcluster-sample
   pgHbaEntries:
     - hostgssenc all           all      0.0.0.0/0     gss
     - hostgssenc all           all      ::1/128       gss
     - hostssl all all 0.0.0.0/0 scram-sha-256
     - hostssl all all ::/0 scram-sha-256
   pgIdentEntries:
     - usermap  active_directory_user postgres_user

יצירת תפקידים במסד נתונים כמשתמש Active Directory

  1. יוצרים תפקיד במסד הנתונים שתואם למשתמש ב-Active Directory. כדי ליצור תפקיד למשתמש ב-Active Directory, מתחברים לאשכול ומריצים את הפקודות הבאות:

    username=# CREATE ROLE "USERNAME@REALM" WITH LOGIN;

  2. נכנסים למסד הנתונים באמצעות משתמש Active Directory. צריך להפעיל את kinit בלקוח שאליו מתחברים. בדוגמה הזו, ל-pod‏ postgres-client מותקנים kinit ו-psql, והוא מוגדר להתחבר לאשכול AlloyDB Omni באמצעות לקוח psql.

    kubectl exec -it postgres-client -n DB_CLUSTER_NAMESPACE -- bash
root:/# kinit USERNAME
Password for USERNAME@REALM:

root:/# psql -h HOSTNAME -d DB_NAME -U USERNAME@REALM
psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1), server 16.3)
GSSAPI-encrypted connection
Type "help" for help.

  3. להריץ שאילתות SQL.

    username=# select * from TABLE_NAME;

השבתת אימות Active Directory

כדי להשבית את האימות ב-Active Directory, מריצים את פקודת Helm הבאה:

helm upgrade alloydbomni-operator PATH_TO_CHART -n alloydb-omni-system --set userDefinedAuthentication.enabled=false

הפקודה מחזירה את הפלט הבא:

Release "alloydbomni-operator" has been upgraded. Happy Helming!
NAME: alloydbomni-operator
LAST DEPLOYED: CURRENT_TIMESTAMP
NAMESPACE: alloydb-omni-system
STATUS: deployed
REVISION: 2
TEST SUITE: None

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