Questa pagina è stata tradotta dall'API Cloud Translation.

Configurare 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. Mostra come configurare GKE Identity Service sui tuoi cluster con il tuo provider Lightweight Directory Access Protocol (LDAP) preferito, tra cui Microsoft Active Directory. Si presume 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 il servizio di identità GKE.

Per saperne di più su come funziona GKE Identity Service 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.

Al momento, GKE Identity Service con LDAP può essere utilizzato solo con GKE on VMware (cluster utente) e GKE 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 eseguire 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 gcloud CLI per utilizzarlo con il tuo progetto.

Durante la configurazione, potresti dover fare riferimento alla documentazione del tuo server LDAP. Le seguenti guide per gli amministratori spiegano la configurazione per alcuni provider LDAP comuni, incluso dove trovare le informazioni necessarie per accedere al server LDAP e configurare i cluster:

Compila il secret dell'account di servizio LDAP

GKE Identity Service ha bisogno di un secret dell'account di servizio per eseguire l'autenticazione sul server LDAP e recuperare i dettagli dell'utente. Nell'autenticazione LDAP sono consentiti due tipi di account di servizio: l'autenticazione di base (che utilizza un nome utente e una password per l'autenticazione sul server) o un certificato client (con una chiave privata del client e un certificato client). Tu o l'amministratore della tua piattaforma dovreste avere queste informazioni sul provider descritte nella sezione Configurare un provider LDAP per il servizio di identità GKE.

Per rendere disponibili le informazioni di accesso al server LDAP per GKE Identity Service, devi creare una risorsa segreto Kubernetes, con i dettagli di accesso descritti 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 del 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 i valori del nome utente e della password che hai ricevuto 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 il certificato TLS e le coppie chiave-valore con il certificato codificato e le coppie chiave-valore che hai ottenuto nel passaggio precedente.

Gli esempi mostrano il secret applicato allo spazio dei nomi anthos-identity-service, che è il nostro approccio consigliato. Il motivo è che, 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 aggiungi un nuovo criterio RBAC per concedere al servizio GKE Identity l'autorizzazione a leggere i secret in quello spazio dei nomi, come indicato di seguito:

---
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 speciale di risorsa personalizzata (CRD) Kubernetes per configurare i tuoi cluster chiamati ClientConfig, con campi per le informazioni sul provider di identità e sui parametri necessari per restituire le informazioni degli utenti. La configurazione di ClientConfig include anche il nome del secret e lo spazio dei nomi del secret che hai creato e applicato nella sezione precedente, consentendo 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

...dove USER_CLUSTER_KUBECONFIG è il percorso del file kubeconfig per il cluster. Se in kubeconfig sono presenti più contesti, viene utilizzato quello corrente. Potrebbe essere necessario reimpostare il contesto attuale sul cluster corretto prima di eseguire il comando.

Di seguito è 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 vengono descritti i campi nel CRD ClientConfig:

Campo	Obbligatorio	Descrizione	Formato
name	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 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 avvengono in testo non crittografato.	string
serviceAccountSecret
name	sì	Nome del secret di Kubernetes che archivia le credenziali dell'account di servizio LDAP.	string
spazio dei nomi	sì	Spazio dei nomi del secret di 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, 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. Questa opzione può essere utilizzata 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 l'autenticazione. Si tratta di un campo distinto dal campo loginAttribute per consentire agli utenti di accedere con un nome utente, ma il loro identificatore effettivo è un indirizzo email o un DN (DN) completo. Ad esempio, l'impostazione di loginAttribute su `sAMAccountName` e identifierAttribute su `userPrincipleName` consente a un utente di accedere come `bsmith`, ma i criteri RBAC effettivi per l'utente saranno scritti come `bsmith@example.com`. Si consiglia di utilizzare `userPrincipleName` poiché è univoco per ogni utente. Se non specificato, il valore predefinito è `userPrincipleName`.	string
loginAttribute	no	Il nome dell'attributo che corrisponde al nome utente inserito. Questo viene utilizzato per trovare l'utente nel database LDAP, ad esempio `(<LoginAttribute>=<username>)`, ed è combinato con il campo del filtro facoltativo. Il valore predefinito è `userPrincipleName`.	string
gruppo
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 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 questo valore è impostato su `distinguishedName`, gli 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, continua a configurare l'accesso degli utenti ai cluster con GKE Identity Service.