Configurare l'autenticazione OIDC sui cluster utente

Questa pagina è rivolta agli amministratori della piattaforma.

Questa pagina descrive come abilitare l'autenticazione OpenID Connect (OIDC) sui cluster utente e configurare il controllo dell'accesso basato sui ruoli (RBAC). Per scoprire di più sull'autenticazione con OIDC, consulta Gestione delle identità con OIDC nei cluster Anthos su Bare Metal.

Abilita l'autenticazione OIDC sui cluster utente

L'autenticazione OIDC può essere abilitata durante la creazione del cluster utente o su un cluster utente esistente. La condizione preliminare per configurare l'autenticazione OIDC è che i profili di identità da applicare al cluster esistono già. Vedi Creare profili di identità.

Imposta profili di identità durante la creazione del cluster

Consulta Creare cluster utente per istruzioni su come creare cluster utente con la Console Anthos Management Center. Nella pagina Configurazione cluster per creare un cluster utente, seleziona i profili identità dall'elenco a discesa Configurazioni AIS. Questi profili di identità verranno applicati al cluster utente.

Imposta profili di identità su un cluster utente esistente

1. Vai alla pagina Identity and Access.

   

2. Fai clic su Applica profili ai cluster.

   

3. Seleziona i profili identità da applicare dall'elenco a discesa Profili.

4. Seleziona i cluster a cui applicare i profili di identità dall'elenco a discesa Cluster.

Visualizza i profili di identità applicati al cluster utente

I profili di identità applicati al cluster utente possono essere visualizzati dalla pagina Identità e accesso.

Seleziona la scheda Cluster, individua il cluster utente da visualizzare e fai clic su Visualizza dettagli configurazione per il cluster utente.

Scarica il file di configurazione del cluster utente

Nella pagina a scorrimento Visualizza dettagli configurazione, fai clic su Scarica configurazione accesso.

Specifica la configurazione OIDC dal file

Crea un file con i contenuti seguenti. Salva questo file come user-cluster-oidc-config.yaml:

spec:
  authentication:
  - name: CONFIGURATION_NAME
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      # The URI to redirect users going through the OAuth flow using cloud
      # console.
      # This is a required parameter not supported by Anthos private mode, so
      # a dummy value is required.
      cloudConsoleRedirectURI: http://cloud.console.not.enabled
      extraParams: EXTRA_PARAMS
      issuerURI: ISSUER_URI
      # The redirect URL that kubectl uses for authorization.
      kubectlRedirectURI: http://localhost:9879/callback
      scopes: SCOPES
      userClaim: USER_CLAIM
      groupsClaim: GROUPS_CLAIM
      certificateAuthorityData: CERT_AUTHORITY_DATA

Sostituisci quanto segue:

• CONFIGURATION_NAME: il nome della configurazione OIDC da creare.
• CLIENT_ID: ID dell'applicazione client che invia richieste di autenticazione al provider OpenID.
• CLIENT_SECRET: secret per l'applicazione client.
• EXTRA_PARAMS: parametri coppia chiave-valore aggiuntivi (separati da virgole) da inviare al provider OpenID.
• ISSUER_URI: URL a cui vengono inviate le richieste di autorizzazione al tuo OpenID.
• SCOPES: ambiti aggiuntivi (separati da virgole) da inviare al provider OpenID.
• USER_CLAIM: dichiarazione JWT da utilizzare come nome utente. Puoi scegliere altre attestazioni, ad esempio email o nome, a seconda del provider OpenID. Tuttavia, alle attestazioni diverse dall'indirizzo email viene aggiunto come prefisso l'URL dell'emittente per evitare conflitti di denominazione.
• GROUPS_CLAIM: nome della rivendicazione nel token ID OIDC in cui sono memorizzate le informazioni sul gruppo dell'utente.
• CERT_AUTHORITY_DATA: un certificato facoltativo con codifica PEM base-64 per il provider OIDC. Rimuovili se non sono necessari. Per creare la stringa codifica il certificato, incluse le intestazioni, in formato base64. Includi la stringa risultante in CertificateAuthorityData come riga singola.

Dopo aver modificato il file con la configurazione desiderata, esegui il comando seguente:

kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG clientconfig default -n kube-public \
  --type=merge --patch "$(cat OIDC_CONFIG)"

Sostituisci quanto segue:

• USER_CLUSTER_KUBECONFIG: percorso del file Kubeconfig del cluster utente.
• OIDC_CONFIG: percorso del file di configurazione creato.

Configurare RBAC sul cluster utente

Questa sezione offre un esempio di come configurare RBAC per concedere l'accesso ai singoli spazi dei nomi. Per informazioni più dettagliate, consulta la documentazione di Kubernetes RBAC.

Supponiamo che siano presenti due spazi dei nomi, workload-a e workload-b. L'obiettivo è rendere le risorse nello spazio dei nomi workload-a leggibili e scrivibili dall'utente [e-mail] e workload-b leggibili dall'utente [e-mail]. [e-mail] non può accedere a workload-b e [e-mail] non può accedere a workload-a.

Crea gli spazi dei nomi nel cluster utente:

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-a
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-b

Per limitare l'accesso a ogni spazio dei nomi, è necessario definire l'autorizzazione per ogni spazio dei nomi. In Kubernetes, puoi eseguire questa operazione creando un Role.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-a
  name: a-full-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]
EOF

Gli elementi verbs definiti per foo-full-access definiscono tutte le azioni che questo ruolo può eseguire nello spazio dei nomi.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-b
  name: b-read-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list"]
EOF

Per b-read-access, i verbi definiti consentono solo al ruolo di eseguire una query per le risorse.

Per poter concedere le autorizzazioni agli utenti, è necessario creare le associazioni dei ruoli. Le associazioni dei ruoli possono includere singoli utenti e gruppi. L'esempio mostra i singoli utenti.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: a-full-access-users
  namespace: workload-a
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: [e-mail] # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: a-full-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

L'associazione dei ruoli (a-full-access-users) precedente concede all'utente [e-mail] le autorizzazioni definite nel ruolo a-full-access. Ciò significa che l'utente [e-mail] è in grado di leggere e scrivere nelle risorse nello spazio dei nomi workload-a.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: b-read-access-users
  namespace: workload-b
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: [e-mail] # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: b-read-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

Questa associazione dei ruoli (b-read-access-users) concede all'utente [e-mail] le autorizzazioni definite nel ruolo b-read-access. Di conseguenza, l'utente [e-mail] può leggere solo le risorse dello spazio dei nomiworkload-b.

Nota: nel campo della produzione, ti consigliamo di associare i ruoli ai gruppi anziché ai singoli utenti. Per informazioni su come esporre i gruppi, rivolgiti al tuo provider OIDC.

Accedi con il provider OIDC

In qualità di amministratore del cluster utente, ottieni il file di configurazione di accesso che deve essere utilizzato da tutti gli utenti del cluster utente. Fai riferimento a Scaricare il file di configurazione dell'accesso per il cluster utente per scaricare la configurazione dell'accesso da Anthos Management Center. In alternativa, puoi creare il file di configurazione dell'accesso eseguendo questo passaggio:

actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
  --output=USER_CLUSTER_NAME-actl-auth-login-config.yaml

Distribuisci USER_CLUSTER_NAME-actl-auth-login-config.yaml agli utenti del cluster utente.

Esegui l'autenticazione con il provider OIDC e segui le istruzioni riportate nella riga di comando:

actl auth login --login-config=USER_CLUSTER_NAME-actl-auth-login-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig \
  --preferred-auth="CONFIGURATION_NAME"

Sostituisci USER_CLUSTER_NAME con il nome del cluster utente mostrato nella Console di amministrazione. --kubeconfig=USER_CLUSTER_NAME-cluster-oidc-kubeconfig è il nome del file di output di Kubeconfig. Sostituisci CONFIGURATION_NAME con il nome del profilo identità con cui eseguire l'autenticazione. Apri USER_CLUSTER_NAME-actl-auth-login-config.yaml per visualizzare i nomi dei profili.

Avviso: l'output Kubeconfig (USER_CLUSTER_NAME-cluster-oidc-kubeconfig sopra riportato) contiene le credenziali utente e non deve essere condiviso.

Usa il nuovo Kubeconfig con kubectl come segue:

kubectl --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig get pods -A

Passaggi successivi

• Scopri di più sulla visualizzazione dei log di controllo.