Configura GKE Identity Service con LDAP

Questo documento è destinato agli amministratori dei cluster o agli operatori delle applicazioni che configurano GKE Identity Service sui propri cluster. Spiega come configurare GKE Identity Service sui cluster con il tuo provider LDAP (Lightweight Directory Access Protocol) preferito, incluso Microsoft Active Directory. Si presuppone che tu o l'amministratore della piattaforma abbiate già ricevuto i dettagli di accesso per il provider LDAP seguendo le istruzioni riportate in Configurare un provider LDAP per GKE Identity Service. Per scoprire di più sul funzionamento del servizio di identità GKE e su altre opzioni di configurazione, consulta la panoramica. Per scoprire come accedere a un cluster utilizzando questo servizio come sviluppatore o altro utente del cluster, consulta Accedere ai cluster con GKE Identity Service. GKE Identity Service con LDAP può essere utilizzato con i deployment di Google Distributed Cloud su VMware (cluster utente) e su bare metal.

Prima di iniziare

1. Assicurati di aver installato i seguenti strumenti a riga di comando:
   • L'ultima versione di Google Cloud CLI, che include gcloud, lo strumento a riga di comando per interagire con Google Cloud. Se devi installare Google Cloud CLI, consulta la guida all'installazione.
   • kubectl per l'esecuzione di comandi sui cluster Kubernetes. Se devi installare kubectl, consulta la guida all'installazione. Se utilizzi Cloud Shell come ambiente shell per interagire con Google Cloud, questi strumenti vengono installati automaticamente.
2. Assicurati di aver inizializzato gcloud CLI per l'utilizzo con il tuo progetto.

Durante questa configurazione, potresti dover consultare la documentazione del server LDAP. Le seguenti guide per amministratori spiegano la configurazione per alcuni provider LDAP popolari, incluso dove trovare le informazioni necessarie per accedere al server LDAP e configurare i cluster:

• OpenLDAP
• Azure AD
• Microsoft Active Directory
• Google LDAP

Compila il secret del account di servizio LDAP

GKE Identity Service ha bisogno di un secret del account di servizio per eseguire l'autenticazione sul server LDAP e recuperare i dettagli dell'utente. Esistono due tipi di account di servizio consentiti nell'autenticazione LDAP: autenticazione di base (che utilizza un nome utente e una password per l'autenticazione al server) o certificato client (che utilizza una chiave privata client e un certificato client). Tu o l'amministratore della piattaforma dovresti disporre di queste informazioni sul tuo provider dopo aver seguito la procedura Configurare un provider LDAP per GKE Identity Service. Per rendere disponibili le informazioni di accesso al server LDAP per GKE Identity Service, devi creare una risorsa Secret Kubernetes con i dettagli di accesso di Configurare un provider LDAP per GKE Identity Service. Gli esempi riportati di seguito mostrano come configurare Secrets per entrambi i tipi di account di servizio. Gli esempi mostrano il secret applicato allo spazio dei nomi anthos-identity-service.

Questo è un esempio di configurazione di un secret di autenticazione di base:

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

dove SERVICE_ACCOUNT_SECRET_NAME è il nome che hai scelto per questo secret. Sostituisci i valori di nome utente e password con quelli ottenuti nel passaggio precedente. USERNAME è un nome utente codificato in Base64 PASSWORD è una password codificata in Base64

Ecco un esempio di configurazione del secret del certificato client:

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 ...

Sostituisci SERVICE_ACCOUNT_SECRET_NAME con il nome che hai scelto per questo secret. Sostituisci i valori della chiave e del certificato TLS con i valori codificati della chiave e del certificato ottenuti nel passaggio precedente.

Gli esempi mostrano il secret applicato allo spazio dei nomi anthos-identity-service, che è l'approccio che consigliamo. Questo perché per impostazione predefinita GKE Identity Service ha l'autorizzazione a leggere i secret in anthos-identity-service. Se vuoi utilizzare un altro spazio dei nomi, modifica i metadati nel secret e poi aggiungi un nuovo criterio RBAC per concedere a GKE Identity Service l'autorizzazione a leggere i secret in quello spazio dei nomi, come segue:

---
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
---

Configura il cluster

GKE Identity Service utilizza un tipo di risorsa personalizzata Kubernetes speciale (CRD) per configurare i cluster chiamato ClientConfig, con campi per informazioni sul provider di identità e sui parametri necessari per restituire le informazioni utente. La configurazione di ClientConfig include anche il nome e lo spazio dei nomi del secret dal secret che hai creato e applicato nella sezione precedente, consentendo a GKE Identity Service di autenticarsi sul server LDAP.

Per applicare la configurazione al cluster, modifica l'oggetto predefinito KRM di tipo clientconfig nello spazio dei nomi kube-public:

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

Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig per il cluster. Se in kubeconfig sono presenti più contesti, viene utilizzato il contesto corrente. Potresti dover reimpostare il contesto attuale sul cluster corretto prima di eseguire il comando.

Di seguito viene mostrato il formato per la configurazione di 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

Suggerimento: GKE Identity Service ti consente di configurare più configurazioni di provider di identità OIDC, LDAP e SAML in una singola risorsa personalizzata (CRD) ClientConfig per l'autenticazione client. Il servizio di identità GKE tenta l'autenticazione con ogni CRD nell'ordine in cui sono definiti e si interrompe dopo la prima autenticazione riuscita.

Puoi configurare più provider di identità in ClientConfig in base ai tuoi requisiti. In questo modo, la gestione viene semplificata e viene offerta flessibilità, consentendoti di configurare diversi metodi di autenticazione all'interno di una risorsa di configurazione unificata. L'esempio seguente ClientConfig definisce più provider di identità nell'ordine richiesto di precedenza dell'autenticazione.

  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
        ...

La tabella seguente descrive i campi nel CRD ClientConfig:

Campo	Obbligatorio	Descrizione	Formato
nome	sì	Un nome per identificare questa configurazione LDAP	string
host	sì	Nome host o indirizzo IP del server LDAP. La porta è facoltativa e, se non specificata, verrà impostata su 389 per impostazione predefinita. Ad esempio, ldap.server.example.com o 10.10.10.10:389.	string
certificateAuthorityData	Obbligatorio per determinati tipi di connessione LDAP	Contiene un certificato dell'autorità di certificazione con codifica Base64 e formato PEM per il server LDAP. Deve essere fornito solo per le connessioni ldaps e startTLS.	string
connectionType	sì	Tipo di connessione LDAP da usare per connettersi al server LDAP. Il valore predefinito è startTLS. La modalità insecure deve essere utilizzata solo per lo sviluppo, poiché tutte le comunicazioni con il server saranno in testo normale.	string
serviceAccountSecret
nome	sì	Nome del secret Kubernetes che archivia le credenziali per il account di servizio LDAP.	string
spazio dei nomi	sì	Spazio dei nomi del secret Kubernetes che archivia le credenziali per il account di servizio LDAP.	string
tipo	sì	Definisce il formato del secret del account di servizio per supportare diversi tipi di secret. Se hai specificato basic-auth nella configurazione del segreto, questo valore deve essere basic, altrimenti deve essere tls. Se non specificato, il valore predefinito è basic.	string
utente
baseDN	sì	La posizione nel sottoalbero della directory LDAP in cui cercare le voci degli utenti.	string
filtro	no	Filtro facoltativo da applicare per cercare l'utente. Può essere utilizzato per limitare ulteriormente gli account utente autorizzati ad accedere. Se non specificato, il valore predefinito è (objectClass=User).	string
identifierAttribute	no	Determina quale attributo utilizzare come identità dell'utente dopo che ha eseguito l'autenticazione. Questo campo è diverso da loginAttribute per consentire agli utenti di accedere con un nome utente, ma poi il loro identificatore effettivo è un indirizzo email o un nome distinto (DN) completo. Ad esempio, se imposti loginAttribute su sAMAccountName e identifierAttribute su userPrincipalName, un utente potrà accedere come bsmith, ma le policy RBAC effettive per l'utente verranno scritte come [e-mail]. L'utilizzo di userPrincipalName è consigliato perché sarà univoco per ogni utente. Se non specificato, il valore predefinito è userPrincipalName.	string
loginAttribute	no	Il nome dell'attributo che corrisponde al nome utente immesso. Viene utilizzato per trovare l'utente nel database LDAP, ad esempio (<LoginAttribute>=<username>), e viene combinato con il campo di filtro facoltativo. Il valore predefinito è userPrincipalName.	string
group (campo facoltativo)
baseDN	sì	La posizione nel sottoalbero della directory LDAP in cui cercare le voci dei gruppi.	string
filtro	no	Filtro facoltativo da utilizzare per cercare i gruppi a cui appartiene un utente. Può essere utilizzato per trovare una corrispondenza esatta solo con determinati gruppi al fine di ridurre il numero di gruppi restituiti per ogni utente. Il valore predefinito è (objectClass=Group).	string
identifierAttribute	no	Il nome che identifica ogni gruppo a cui appartiene un utente. Ad esempio, se questo valore è impostato su distinguishedName, i RBAC e le altre aspettative del gruppo devono essere scritti come DN completi. Se non specificato, il valore predefinito è distinguishedName.	string

Passaggi successivi

Una volta applicata la configurazione, continua a configurare l'accesso degli utenti ai cluster con GKE Identity Service.