詳情請參閱「Active Directory 總覽」。
本文假設您已熟悉如何套用 Kubernetes 資訊清單檔案,以及如何使用 kubectl 指令列工具。詳情請參閱「指令列工具 (kubectl)」。
事前準備
如要啟用 Active Directory 整合功能,您必須具備下列條件:
- 部署在 Kubernetes 環境中的 AlloyDB Omni 叢集
- Active Directory 伺服器 keytab
從 AlloyDB Omni Kubernetes 運算子 1.4.0 版遷移至 1.5.0 版
如果您在 AlloyDB Omni 運算子 1.4.0 版或更早版本中使用 Active Directory 整合功能,請務必遷移至 AlloyDB Omni 運算子 1.5.0 版。
如要遷移至 AlloyDB Omni 運算子 1.5.0 版,請按照下列步驟操作:
- 將 AlloyDB Omni 運算子升級至 1.5.0 版。
- 建立使用者定義的驗證資源。
- 建立新的 UserDefinedAuthentication 資源資訊清單。
- 在
spec.dbclusterRef
中填入目標 DBCluster 名稱。 - 在
spec.keytabSecretRef
中填入 keytab 密鑰的名稱。 - 將與 Active Directory 和 Kerberos 驗證相關的現有
pg_hba.conf
規則複製到spec.pgHbaEntries
欄位。 - 將現有的
pg_ident.conf rules
(如有) 複製到spec.pgIdentEntries
欄位。 - 套用這個新資訊清單,例如
kubectl apply -f user-auth-crd.yaml
。
- 移除預先發布版設定並重新部署叢集。
- 在 DBCluster 資源定義中,移除先前用於設定 Active Directory 整合的所有註解,例如以主機為準的身分驗證 (HBA) 規則、ident 規則和 keytab 檔案註解。
- 刪除您建立的
pg_hba
和pg_ident
設定對應。 - 重新套用更新後的 DBCluster 資訊清單。
設定 Active Directory 支援
使用 keytab 建立及套用密鑰:
apiVersion: v1 kind: Secret metadata: name: KEYTAB_SECRET_NAME namespace: DB_CLUSTER_NAMESPACE type: Opaque data: krb5.keytab: | KEYTAB_FILE_CONTENT
以下範例指令會在 Active Directory 伺服器上產生 keytab:
ktpass /princ postgres/DBCLUSTER_HOST@REALM /Pass PASSWORD /mapuser postgres /crypto ALL /ptype KRB5_NT_Principal /out OUTPUT_PATH
ALLOYDB_HOST
是指向 DBCluster 或 DBCluster IP 位址的主機。套用下列使用者定義的驗證自訂資源資訊清單:
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
項目。如要實作使用者名稱對應,請在pg_hba.conf
檔案的選項欄位中指定map=
。詳情請參閱「識別地圖」。請參閱以下範例:
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 使用者身分建立資料庫角色
在資料庫中建立與 Active Directory 使用者相符的角色。 如要為 Active Directory 使用者建立角色,請連線至叢集,然後執行下列指令:
username=# CREATE ROLE "USERNAME@REALM" WITH LOGIN;
使用 Active Directory 使用者登入資料庫。您必須在連線的用戶端中啟用
kinit
。在本範例中,postgres-client
Pod 已安裝 kinit 和 psql,並設定為使用 psql 用戶端連線至 AlloyDB Omni 叢集。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.
執行 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
後續步驟
- 將 Active Directory 使用者支援功能與 AlloyDB Omni 整合。
- 將 Active Directory 群組支援功能與 AlloyDB Omni 整合。
- 在 Kubernetes 上整合 Active Directory 群組支援。
- 排解 AlloyDB Omni 中的 Active Directory 整合問題。