使用 LDAP 設定 GKE Identity Service

本文適用於叢集管理員或應用程式運算子,在叢集上設定 GKE Identity Service。本文說明如何使用偏好的輕量型目錄存取通訊協定 (LDAP) 提供者 (包括 Microsoft Active Directory),在叢集上設定 GKE Identity Service。本文假設您或平台管理員已按照「為 GKE Identity Service 設定 LDAP 供應商」一文中的操作說明,取得 LDAP 供應商的登入詳細資料。 如要進一步瞭解 GKE Identity Service 的運作方式和其他設定選項,請參閱總覽。如要瞭解如何以開發人員或其他叢集使用者的身分,透過這項服務存取叢集,請參閱「透過 GKE Identity Service 存取叢集」。GKE Identity Service with LDAP 僅適用於 Google Distributed Cloud 部署作業,包括 on VMware (使用者叢集) 和 on Bare Metal

事前準備

  1. 確認您已安裝下列指令列工具:
    • 最新版 Google Cloud CLI,其中包含 gcloud,這是與 Google Cloud互動的指令列工具。如需安裝 Google Cloud CLI,請參閱安裝指南
    • kubectl,可對 Kubernetes 叢集執行指令。如需安裝 kubectl,請參閱安裝指南。 如果您使用 Cloud Shell 做為與 Google Cloud互動的 Shell 環境,系統會為您安裝這些工具。
  2. 確認您已初始化 gcloud CLI,以便搭配專案使用。

在整個設定過程中,您可能需要參閱 LDAP 伺服器的說明文件。下列管理員指南說明如何為部分熱門 LDAP 供應商設定服務,包括如何尋找登入 LDAP 伺服器及設定叢集所需的資訊:

填入 LDAP 服務帳戶密碼

GKE Identity Service 需要服務帳戶密鑰,才能向 LDAP 伺服器驗證身分並擷取使用者詳細資料。LDAP 驗證允許兩種服務帳戶:基本驗證 (使用使用者名稱和密碼向伺服器驗證) 或用戶端憑證 (使用用戶端私密金鑰和用戶端憑證)。您或平台管理員應已透過「為 GKE Identity Service 設定 LDAP 提供者」一文,取得提供者的相關資訊。如要讓 GKE Identity Service 存取 LDAP 伺服器登入資訊,您需要建立 Kubernetes Secret 資源,並使用「為 GKE Identity Service 設定 LDAP 供應商」中的登入詳細資料。 下列範例說明如何為這兩種類型的服務帳戶設定密鑰。範例顯示密鑰套用至 anthos-identity-service 命名空間。

以下是基本驗證密鑰設定範例:

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: "anthos-identity-service"
type: kubernetes.io/basic-auth     # Make sure the type is correct
data:
  username: USERNAME  # Use a base64-encoded username
  password: PASSWORD  # Use a base64-encoded password

其中, SERVICE_ACCOUNT_SECRET_NAME 是您為這個 Secret 選擇的名稱。 將使用者名稱和密碼值,換成您在上一步取得的使用者名稱和密碼。 USERNAME 是 Base64 編碼的使用者名稱 PASSWORD 是 Base64 編碼的密碼

以下是用戶端憑證密鑰設定範例:

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: anthos-identity-service
type: kubernetes.io/tls            # Make sure the type is correct
data:
  # the data is abbreviated in this example
  tls.crt: |
       MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
  tls.key: |
       MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...

SERVICE_ACCOUNT_SECRET_NAME 替換為您為這個 Secret 選擇的名稱。將 TLS 憑證和金鑰值,換成您在上一步取得的編碼憑證和金鑰值。

範例顯示密鑰已套用至 anthos-identity-service 命名空間,這是我們建議的做法。這是因為根據預設,GKE Identity Service 有權讀取 anthos-identity-service 中的 Secret。如要使用其他命名空間,請變更密鑰中的中繼資料,然後新增 RBAC 政策,授予 GKE Identity Service 讀取該命名空間中密鑰的權限,如下所示:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: NAMESPACE
  name: ais-secret-reader-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ais-secret-reader-role-binding
  namespace: NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ais-secret-reader-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: anthos-identity-service
---

設定叢集

GKE Identity Service 會使用特殊的 Kubernetes 自訂資源類型 (CRD) 來設定叢集,稱為 ClientConfig,其中包含身分識別提供者資訊的欄位,以及傳回使用者資訊所需的參數。您的 ClientConfig 設定也包含您在上一個部分建立及套用的 Secret 中的密鑰名稱和命名空間,讓 GKE Identity Service 可以向 LDAP 伺服器進行驗證。

如要將設定套用至叢集,請在 kube-public 命名空間中,編輯 clientconfig 類型的 KRM 預設物件:

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

USER_CLUSTER_KUBECONFIG 替換為叢集的 kubeconfig 檔案路徑。如果 kubeconfig 中有多個環境,系統會使用目前的環境。執行指令前,您可能需要將目前的環境重設為正確的叢集。

以下顯示 ClientConfig 設定的格式:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
    - name: NAME_STRING
      ldap:
        host: HOST_NAME
        certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
        connectionType: CONNECTION_TYPE
        serviceAccountSecret:
          name: SERVICE_ACCOUNT_SECRET_NAME
          namespace: NAMESPACE
          type: SECRET_FORMAT
        user:
          baseDN: BASE_DN
          filter: FILTER
          identifierAttribute: IDENTIFIER_ATTRIBUTE
          loginAttribute: LOGIN_ATTRIBUTE
        group:
          baseDN: BASE_DN
          filter: FILTER
          identifierAttribute: IDENTIFIER_ATTRIBUTE

您可以根據需求,在 ClientConfig 中設定多個身分識別提供者。這項功能可簡化管理作業並提供彈性,讓您在統一的設定資源中設定各種驗證方法。下列範例 ClientConfig 會以驗證優先順序的必要順序,定義多個身分識別提供者。

  apiVersion: v1
  items:
  - apiVersion: authentication.gke.io/v2alpha1
    kind: ClientConfig
  ...
    spec:
      authentication:
      - aws:
          region: us-west-2
        name: AWS Login
      - ldap:
      ...
      - saml:
        ...
      - azureAD:
        ...
      - oidc:
        name: Okta OIDC
        ...
      -oidc:
        name: Google OIDC
        ...

下表說明 ClientConfig CRD 中的欄位:

欄位 必填 說明 格式
name 識別這項 LDAP 設定的名稱 string
主機 LDAP 伺服器的主機名稱或 IP 位址。通訊埠為選用項目,如未指定,則預設為 389。例如 ldap.server.example.com10.10.10.10:389 string
certificateAuthorityData 特定 LDAP 連線類型必須提供此資訊 包含採用 Base64 編碼和 PEM 格式的 LDAP 伺服器憑證授權單位憑證。只有在 ldapsstartTLS 連線時,才需要提供這項資訊。 string
connectionType 連至 LDAP 伺服器時要使用的 LDAP 連線類型,預設值為 startTLSinsecure 模式只能用於開發,因為與伺服器的所有通訊都會以純文字形式進行。 string
serviceAccountSecret
name 儲存 LDAP 服務帳戶憑證的 Kubernetes 密鑰名稱。 string
namespace 儲存 LDAP 服務帳戶憑證的 Kubernetes 密鑰命名空間。 string
type 定義服務帳戶密鑰的格式,以便支援不同類型的密鑰。如果您在 Secret 設定中指定 basic-auth,則應為 basic,否則應為 tls。如未指定,則預設為 basic string
使用者
baseDN LDAP 目錄中子樹的位置,用來搜尋使用者項目。 string
篩選器 搜尋使用者時要套用的篩選器 (選用)。這項功能可用於進一步限制允許登入的使用者帳戶。如未指定,則預設為 (objectClass=User) string
identifierAttribute 決定通過驗證的使用者用來表示身分的屬性。這與 loginAttribute 欄位不同,可讓使用者以使用者名稱登入,但實際 ID 為電子郵件地址或完整辨別名稱 (DN)。舉例來說,如果將 loginAttribute 設為 sAMAccountName,identifierAttribute 設為 userPrincipalName,使用者就能以 bsmith 登入,但使用者實際的 RBAC 政策會寫成 bsmith@example.com。建議使用 userPrincipalName,因為每位使用者都會有專屬的 ID。如未指定,則預設值為 userPrincipalName string
loginAttribute 用來比對輸入使用者名稱的屬性名稱。這項資訊用於在 LDAP 資料庫中尋找使用者 (例如 (<LoginAttribute>=<username>)),並與選用的篩選器欄位合併。預設值為 userPrincipalName string
group (選填欄位)
baseDN LDAP 目錄中子樹的位置,用來搜尋群組項目。 string
篩選器 搜尋使用者所屬群組時要套用的篩選器 (選用)。這項功能可用於明確比對特定群組,減少每個使用者傳回的群組數量。預設值為 (objectClass=Group) string
identifierAttribute 使用者所屬各群組的識別名稱。舉例來說,如果設為 distinguishedName,則 RBAC 和其他群組期望值應以完整 DN 形式撰寫。如未指定,則預設值為 distinguishedName string

後續步驟

套用設定後,請繼續設定使用者存取叢集的權限 (使用 GKE Identity Service)