Questa pagina è stata tradotta dall'API Cloud Translation.

Configura il servizio di identità GKE con LDAP

Questo documento è rivolto agli amministratori di cluster o agli operatori di 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 presume che tu o l'amministratore della piattaforma abbiate già ricevuto i dettagli di accesso del provider LDAP seguendo le istruzioni riportate in Configurare un provider LDAP per GKE Identity Service.

Per saperne di più su come funziona GKE Identity Service e su altre opzioni di configurazione, consulta la panoramica. Per informazioni su come accedere a un cluster utilizzando questo servizio come sviluppatore o altro utente del cluster, vedi Accedere ai cluster con GKE Identity Service.

Al momento GKE Identity Service con LDAP può essere utilizzato solo con GKE on VMware (cluster utente) e GKE on Bare Metal.

Prima di iniziare

Assicurati di avere 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 sono installati automaticamente.
Assicurati di aver inizializzato l'interfaccia alla gcloud CLI per utilizzarla con il tuo progetto.

Durante questa configurazione, potrebbe essere necessario fare riferimento alla documentazione del tuo server LDAP. Le seguenti guide per gli amministratori spiegano la configurazione di alcuni provider LDAP noti e spiegano dove trovare le informazioni necessarie per accedere al server LDAP e configurare i cluster:

Compilare il secret dell'account di servizio LDAP

GKE Identity Service richiede un secret dell'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: l'autenticazione di base (che utilizza un nome utente e una password per eseguire l'autenticazione sul server) o un certificato client (utilizzando una chiave privata e un certificato client). Tu o l'amministratore di piattaforma dovete avere queste informazioni sul provider consultando la sezione 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 in Configurare un provider LDAP per GKE Identity Service.

Gli esempi seguenti mostrano come configurare i secret per entrambi i tipi di account di servizio. Gli esempi mostrano il secret applicato allo spazio dei nomi anthos-identity-service.

Ecco un esempio di configurazione di auth Secret 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 del nome utente e della password con quelli inseriti nel passaggio precedente. USERNAME è un nome utente con codifica Base64 PASSWORD è una password con codifica Base64

Ecco un esempio di configurazione del secret di un 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 ...

...dove SERVICE_ACCOUNT_SECRET_NAME è il nome che hai scelto per questo secret. Sostituisci i valori del certificato e delle chiavi TLS con i valori del certificato e delle chiavi codificati nel passaggio precedente.

Gli esempi mostrano l'applicazione del secret allo spazio dei nomi anthos-identity-service, che è il nostro approccio consigliato. Questo perché, per impostazione predefinita, il servizio di identità GKE ha l'autorizzazione a leggere i secret in anthos-identity-service. Se vuoi utilizzare un altro spazio dei nomi, modifica i metadati nel secret, quindi aggiungi un nuovo criterio RBAC per concedere l'autorizzazione del servizio di identità GKE a leggere i secret al suo interno, 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 uno speciale tipo di risorsa personalizzata (CRD) Kubernetes per configurare i tuoi cluster chiamati ClientConfig, con campi per informazioni sul provider di identità e sui parametri necessari per restituire informazioni sugli utenti. La configurazione ClientConfig include anche il nome e lo spazio dei nomi del secret del secret che hai creato e applicato nella sezione precedente, consentendo al servizio di identità GKE di eseguire l'autenticazione 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

...dove USER_CLUSTER_KUBECONFIG è il percorso del file kubeconfig per il cluster. Se sono presenti più contesti in kubeconfig, viene utilizzato quello attuale. Potresti dover reimpostare il contesto attuale nel cluster corretto prima di eseguire il comando.

Di seguito viene mostrato il formato per la configurazione di ClientConfig:

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

Nella tabella seguente sono descritti i campi della 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, il valore predefinito sarà 389. Ad esempio, `ldap.server.example.com` o `10.10.10.10:389`.	string
certificateAuthorityData	Obbligatorio per alcuni tipi di connessioni 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 non crittografato.	string
serviceAccountSecret
nome	sì	Nome del secret Kubernetes in cui sono archiviate le credenziali dell'account di servizio LDAP.	string
spazio dei nomi	sì	Spazio dei nomi del secret Kubernetes in cui sono archiviate le credenziali dell'account di servizio LDAP.	string
Tipo	sì	Definisce il formato del secret dell'account di servizio per supportare diversi tipi di secret. Se hai specificato `basic-auth` nella configurazione del secret, 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
filtra	no	Filtro facoltativo da applicare per cercare l'utente. Questa opzione può essere utilizzata per limitare ulteriormente gli account utente a cui è consentito l'accesso. Se non specificato, il valore predefinito è `(objectClass=User)`.	string
identifierAttribute	no	Determina quale attributo utilizzare come identità dell'utente dopo l'autenticazione. Questo è diverso dal campo loginAttribute per consentire agli utenti di accedere con un nome utente, ma in modo che il loro identificatore effettivo sia un indirizzo email o un DN (DN) completo. Ad esempio, l'impostazione di loginAttribute su `sAMAccountName` e diidentifierAttribute su `userPrincipalName` consente a un utente di accedere come `bsmith`, ma i criteri RBAC effettivi per l'utente vengono scritti come `bsmith@example.com`. Ti consigliamo di utilizzare `userPrincipalName` poiché sarà univoco per ogni utente. Se non specificato, il valore predefinito è `userPrincipalName`.	string
loginAttribute	no	Il nome dell'attributo che corrisponde al nome utente inserito. Viene utilizzato per trovare l'utente nel database LDAP, ad esempio `(<LoginAttribute>=<username>)`, e viene combinato con il campo facoltativo del filtro. Il valore predefinito è `userPrincipalName`.	string
gruppo (campo facoltativo)
baseDN	sì	La posizione nel sottoalbero della directory LDAP in cui cercare le voci dei gruppi.	string
filtra	no	Filtro facoltativo da utilizzare per cercare i gruppi a cui appartiene un utente. Può essere utilizzato per associare esplicitamente solo 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 il criterio viene 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

Che cosa succede dopo?

Dopo aver applicato la configurazione, passa alla configurazione dell'accesso degli utenti ai cluster con GKE Identity Service.