שילוב תמיכה במשתמשי 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

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

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

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

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

    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

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