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 nei tuoi cluster con il provider Lightweight Directory Access Protocol (LDAP) che preferisci, incluso Microsoft Active Directory. Si presume che tu o l'amministratore della piattaforma abbiate già i dati di accesso per il provider LDAP seguendo le istruzioni riportate in Configurare un provider LDAP per il servizio GKE Identity. 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. GKE Identity Service con LDAP può essere utilizzato con i deployment Google Distributed Cloud su VMware (cluster utente) e solo su Bare Metal.

Prima di iniziare

Assicurati di aver installato i seguenti strumenti a riga di comando:
- La versione più recente 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 la gcloud CLI da utilizzare 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:

Compila il segreto 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: autenticazione di base (utilizzo di un nome utente e una password per l'autenticazione al server) o certificato client (utilizzo di una chiave privata e un certificato client). Tu o l'amministratore della piattaforma dovreste disporre di queste informazioni sul fornitore seguendo la procedura descritta in 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.

Questo è un esempio di configurazione di un segreto 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 del nome utente e della password con quelli che hai ottenuto 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 ...

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 della chiave e del certificato codificati ottenuti 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 al servizio di identità GKE l'autorizzazione 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 una piattaforma Kubernetes risorsa personalizzata (CRD) per configurare i cluster chiamati ClientConfig, con campi per informazioni sul provider di identità e sui parametri che deve restituire le informazioni dell'utente. La tua configurazione ClientConfig include anche il secret e spazio dei nomi del secret che hai creato e applicato nella precedente che consente a GKE Identity Service 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

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 lo stato attuale il contesto nel cluster corretto prima di eseguire il comando.

Di seguito è riportato 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

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 è 389. 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é tutta la comunicazione con il server sarà in testo non cifrato.	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 del sottoalbero nella directory LDAP in cui cercare le voci degli utenti.	string
filtro	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 da utilizzare come identità dell'utente dopo l'autenticazione. Questo campo è diverso dal campo loginAttribute per consentire agli utenti di accedere con un nome utente, ma poi avere il loro identificatore effettivo come indirizzo email o nome distinto (DN) completo. Ad esempio, impostando loginAttribute a `sAMAccountName` eidentifierAttribute a `userPrincipalName` consente a un utente di accedere come `bsmith`, ma in realtà I criteri RBAC 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 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. Questo può essere utilizzato per associare in modo esplicito solo determinati gruppi al fine di ridurre la quantità 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 altre aspettative del gruppo devono essere scritti come DN completi. Se non specificato, il valore predefinito è `distinguishedName`.	string

Passaggi successivi

Dopo aver applicato la configurazione, continua a configurare l'accesso degli utenti ai cluster con GKE Identity Service.