Questo documento descrive come gli amministratori dei cluster o gli operatori delle applicazioni possono configurare i cluster Kubernetes per supportare l'autenticazione da un provider Lightweight Directory Access Protocol (LDAP) di terze parti, come Microsoft Entra ID o Google LDAP. Per saperne di più, consulta Informazioni sull'autenticazione tramite identità di terze parti.
Limitazioni
Devi utilizzare un tipo di cluster che supporti LDAP.
Prima di iniziare
-
Installa Google Cloud CLI.
-
Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.
-
Per inizializzare gcloud CLI, esegui questo comando:
gcloud init -
Dopo aver inizializzato gcloud CLI, aggiornala e installa i componenti richiesti:
gcloud components update gcloud components install kubectl
- Assicurati che l'amministratore della piattaforma ti abbia fornito tutte le informazioni sul provider di cui hai bisogno. Per saperne di più, consulta Configurare i provider LDAP per l'autenticazione nei cluster.
Durante questa configurazione, potresti dover consultare la documentazione del server LDAP. Le seguenti guide per gli amministratori spiegano la configurazione di alcuni provider LDAP più diffusi, incluso dove trovare le informazioni necessarie per accedere al server LDAP e configurare i cluster:
Compilare il secret dell'account di servizio LDAP
Il cluster ha bisogno di un secret dell'account di servizio per eseguire l'autenticazione sul server LDAP e recuperare i dettagli dell'utente. L'autenticazione LDAP supporta i seguenti meccanismi:
- Autenticazione di base, in cui utilizzi un nome utente e una password.
- Autenticazione con certificato client, in cui utilizzi una chiave privata client e un certificato client.
Tu o l'amministratore della piattaforma dovresti avere queste informazioni
sul provider dopo aver seguito la procedura descritta in
Configurare i provider LDAP per l'autenticazione nei cluster.
Per rendere disponibili al cluster le informazioni di accesso al server LDAP, devi
creare un
secret Kubernetes
contenente i dettagli di accesso LDAP.
Gli esempi seguenti mostrano come configurare i secret per entrambi i tipi di autenticazione. Gli esempi mostrano l'applicazione del secret allo spazio dei nomi anthos-identity-service.
Di seguito è riportato un esempio di configurazione di un 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 il nome utente e la password che hai ottenuto nel passaggio precedente. USERNAME è un nome utente con codifica Base64 PASSWORD è una password con codifica Base64
Di seguito è riportato un esempio di configurazione di un secret di 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 di certificato e chiave TLS con i valori di certificato e chiave codificati che hai ottenuto nel passaggio precedente.
Gli esempi mostrano l'applicazione del secret allo spazio dei nomi anthos-identity-service. Per impostazione predefinita, i componenti di sistema hanno l'autorizzazione per leggere i secret in questo spazio dei nomi. Per utilizzare un altro spazio dei nomi, modifica i metadati nel secret e poi aggiungi una nuova policy RBAC per concedere l'autorizzazione a leggere i secret in quello spazio dei nomi al ServiceAccount default nello spazio dei nomi anthos-identity-service, 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 ---
Configurare il cluster
Per configurare l'autenticazione a un cluster utilizzando LDAP, aggiungi le seguenti informazioni a una risorsa personalizzata Kubernetes denominata ClientConfig:
- Informazioni sul provider di identità e sui parametri necessari per restituire le informazioni sull'utente.
- Il nome e lo spazio dei nomi del secret che hai creato e applicato nel passaggio precedente, che consente al cluster di eseguire l'autenticazione sul server LDAP.
Per configurare il cluster, modifica il ClientConfig default 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 nel 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
ldap:
certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
connectionType: CONNECTION_TYPE
host: HOST_NAME
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
Puoi aggiungere più configurazioni di provider di identità OIDC, LDAP e SAML allo stesso ClientConfig. Il cluster tenta di eseguire l'autenticazione con ogni configurazione nell'ordine in cui sono definite e si interrompe dopo la prima autenticazione riuscita. Il seguente esempio di ClientConfig definisce più provider di identità in un ordine specifico:
apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
name: default
namespace: kube-public
spec:
authentication:
- aws:
region: us-west-2
name: AWS Login
- ldap:
# Multiple lines are omitted here.
- saml:
# Multiple lines are omitted here.
- azureAD:
# Multiple lines are omitted here.
- oidc:
name: Okta OIDC
# Multiple lines are omitted here.
- oidc:
name: Google OIDC
# Multiple lines are omitted here.
Campi LDAP di ClientConfig
La tabella seguente descrive i campi dell'oggetto ldap di ClientConfig. I campi che devi aggiungere dipendono dai token del provider di identità e dalla modalità di configurazione del provider da parte dell'amministratore della piattaforma.
| 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, viene impostata come predefinita 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. Questo 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 normale.
|
string |
| serviceAccountSecret | |||
| nome | sì | Nome del secret Kubernetes che archivia le credenziali per l'account di servizio LDAP. | string |
| spazio dei nomi | sì | Spazio dei nomi del secret Kubernetes che archivia 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 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. Può essere utilizzato per limitare ulteriormente gli account utente autorizzati ad accedere. Se non specificato, il valore predefinito è (objectClass=User).
|
string |
| identifierAttribute | no | Determina l'attributo
da utilizzare 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 il loro identificatore effettivo è un indirizzo email o un nome distinto (DN) completo. Ad esempio, se imposti loginAttribute
su sAMAccountName e identifierAttribute su userPrincipalName
, un utente può accedere come bsmith, ma le policy RBAC effettive
per l'utente verranno scritte come bsmith@example.com.
È consigliabile utilizzare userPrincipalName, poiché questo
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 filtro facoltativo. 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 |
| filtro | no | Filtro facoltativo da utilizzare per cercare i gruppi a cui appartiene un utente. Può essere utilizzato per trovare esplicitamente 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 controlli RBAC e le 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 utente da provider esterni ai cluster.