Questa pagina è stata tradotta dall'API Cloud Translation.

Configura i cluster membri del parco risorse per l'autenticazione LDAP

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, ad esempio Microsoft Entra ID o Google LDAP. Per ulteriori informazioni, vedi Informazioni sull'autenticazione tramite identità di terze parti.

Limitazioni

Devi utilizzare un tipo di cluster che supporta LDAP.

Prima di iniziare

Install the 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 del fornitore di cui hai bisogno. Per saperne di più, consulta Configurare i provider LDAP per l'autenticazione ai cluster.

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

Compila il secret del service account LDAP

Il cluster ha bisogno di un secret del service account per l'autenticazione al server LDAP e per 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 dovreste disporre di queste informazioni sul tuo provider seguendo la procedura descritta in Configurare i provider LDAP per l'autenticazione ai cluster. Per rendere disponibili al cluster le informazioni di accesso al server LDAP, devi creare un secret Kubernetes che contenga 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.

Questo è un esempio di configurazione di base di un secret di autenticazione:

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 quelli ottenuti nel passaggio precedente. USERNAME è un nome utente codificato in Base64 PASSWORD è una password codificata in Base64

Ecco 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 del certificato e della chiave TLS con i valori codificati del certificato e della chiave ottenuti nel passaggio precedente.

Gli esempi mostrano il secret applicato 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 un nuovo criterio RBAC per concedere l'autorizzazione a leggere i secret in quello spazio dei nomi all'default ServiceAccount 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
---

Configura 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 utente.
Il nome e lo spazio dei nomi del secret che hai creato e applicato nel passaggio precedente, che consente al cluster di autenticarsi al server LDAP.

Per configurare il cluster, modifica default 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 attuale. Potresti dover reimpostare il contesto attuale sul cluster corretto prima di eseguire il comando.

Di seguito viene mostrato il formato per la configurazione 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 autenticarsi con ogni configurazione nell'ordine in cui sono definite e si arresta dopo la prima autenticazione riuscita. L'esempio ClientConfig seguente 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 ClientConfig

La tabella seguente descrive i campi dell'oggetto ClientConfig ldap. I campi che devi aggiungere dipendono dai token del provider di identità e dal modo in cui l'amministratore della piattaforma ha configurato il provider.

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, verrà impostata su 389 per impostazione predefinita. 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é tutte le comunicazioni con il server saranno in testo normale.	string
serviceAccountSecret
nome	sì	Nome del secret Kubernetes che archivia le credenziali per il service account LDAP.	string
spazio dei nomi	sì	Spazio dei nomi del secret Kubernetes che archivia le credenziali per il service account LDAP.	string
tipo	sì	Definisce il formato del secret del service account per supportare diversi tipi di secret. Se hai specificato `basic-auth` nella configurazione del segreto, 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 quale attributo utilizzare come identità dell'utente dopo che ha eseguito l'autenticazione. Questo campo è diverso da loginAttribute per consentire agli utenti di accedere con un nome utente, ma poi 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 potrà accedere come `bsmith`, ma le policy RBAC effettive per l'utente verranno scritte come `bsmith@example.com`. L'utilizzo di `userPrincipalName` è consigliato perché 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
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. Può essere utilizzato per trovare una corrispondenza esatta solo con 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`, i controlli dell'accesso basato sui ruoli e le altre aspettative del gruppo devono essere scritti come DN completi. Se non specificato, il valore predefinito è `distinguishedName`.	string

Passaggi successivi

Una volta applicata la configurazione, continua a configurare l'accesso degli utenti dai provider esterni ai cluster.

Configura i cluster membri del parco risorse per l'autenticazione LDAP Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.