Questa pagina è stata tradotta dall'API Cloud Translation.

Configurare GKE Identity Service con LDAP

Questo documento è rivolto agli amministratori dei cluster o agli operatori delle applicazioni che configurano GKE Identity Service sui propri cluster. Spiega come configurare GKE Identity Service sui 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 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

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 vengono installati per te.
Assicurati di aver inizializzato gcloud CLI per l'utilizzo con il tuo progetto.

Durante la configurazione, potresti dover consultare la documentazione del tuo server LDAP. Le seguenti guide per gli amministratori spiegano la configurazione di alcuni provider LDAP comuni, incluso 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 ha bisogno di un segreto dell'account di servizio per autenticarsi al 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 Kubernetes Secret con i dettagli di accesso descritti in Configurare un provider LDAP per GKE Identity Service. Gli esempi riportati di seguito mostrano come configurare i segreti 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

Questo è 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 della chiave e del certificato codificati ottenuti nel passaggio precedente.

Gli esempi mostrano il segreto applicato allo spazio dei nomi anthos-identity-service, che è il nostro approccio consigliato. 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 segreto e aggiungi un nuovo criterio RBAC per concedere a GKE Identity Service l'autorizzazione a leggere i segreti in quel determinato 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 speciale di risorsa personalizzata (CRD) Kubernetes per configurare i cluster chiamato ClientConfig, con campi per le informazioni sul provider di identità e sui parametri necessari per restituire le informazioni utente. La configurazione ClientConfig include anche il nome e il nome spazio dei secret del secret che hai creato e applicato nella sezione precedente, consentendo a GKE Identity Service di autenticarsi al 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. Prima di eseguire il comando, potresti dover reimpostare il contesto corrente sul cluster corretto.

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

La tabella seguente descrive i campi nel file ClientConfig CRD:

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 che memorizza le credenziali per l'account di servizio LDAP.	string
spazio dei nomi	sì	Spazio dei nomi del secret Kubernetes che memorizza le credenziali per l'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 segreto, 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. Questo può essere utilizzato per limitare ulteriormente gli account utente che possono accedere. Se non specificato, il valore predefinito è `(objectClass=User)`.	string
identifierAttribute	no	Determina quale attributo da usare come identità dell'utente dopo che ha eseguito 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, l'impostazione di loginAttribute su `sAMAccountName` e di identifierAttribute su `userPrincipalName` consentirebbe a un utente di accedere come `bsmith`, ma i criteri RBAC effettivi per l'utente verrebbero 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 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. 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`, le RBAC e altre aspettative di gruppo devono essere scritte 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.