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 installarekubectl
, consulta la guida all'installazione. Se utilizzi Cloud Shell come ambiente shell per interagire con Google Cloud, questi strumenti vengono installati per te.
- La versione più recente di Google Cloud CLI, che include
- 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.