Configurazione di identità e sicurezza

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

In questa pagina viene descritto come abilitare l'autenticazione OpenID Connect (OIDC) sui cluster utente, come configurare il controllo dell'accesso basato sui ruoli (RBAC) e come utilizzare il servizio SSO (Single Sign-On) di Google per l'autenticazione. 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 in un cluster utente esistente. La condizione preliminare per la configurazione dell'autenticazione OIDC è che esistano già i profili di identità da applicare al cluster. Consulta Creazione di profili di identità.

Imposta profili di identità durante la creazione del cluster

Per istruzioni su come creare cluster utente, consulta Creare cluster utente tramite l'interfaccia utente del Centro gestione. Nella pagina Configurazione cluster per creare un cluster utente, seleziona i profili di 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 Identità e accesso.

   

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.

Visualizzare 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, quindi fai clic su Visualizza dettagli configurazione per il cluster utente.

Scarica il file di configurazione dell'accesso al cluster utente

Nella pagina visualizzata Mostra 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 isolated 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 le 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 che contiene le informazioni sul gruppo dell'utente.
• CERT_AUTHORITY_DATA: un certificato facoltativo con codifica PEM base64 per il provider OIDC. Rimuovile se non sono necessarie. Per creare la stringa codifica il certificato, incluse le intestazioni, in base64. Includi la stringa risultante in CertificateAuthorityData come singola riga.

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 al file di configurazione che hai creato.

Configurazione di RBAC nel cluster utente

Questa sezione fornisce 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 ci siano 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. 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

I 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 concedere agli utenti le autorizzazioni, è necessario creare i RoleBinding. Le associazioni dei ruoli possono includere singoli utenti e gruppi. Questo esempio mostra 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 dallo spazio dei nomi workload-b.

Nota: in produzione, consigliamo di associare i ruoli ai gruppi anziché ai singoli utenti. Rivolgiti al tuo provider OIDC per informazioni su come esporre i gruppi.

Accedi con il provider OIDC

In qualità di amministratore del cluster utente, richiedi il file di configurazione dell'accesso che sarà utilizzato da tutti gli utenti del cluster. Fai riferimento a Scarica il file di configurazione dell'accesso al cluster utente per scaricare la configurazione dell'accesso dall'interfaccia utente del Centro di gestione in modalità privata di Anthos. In alternativa, puoi creare il file di configurazione di accesso eseguendo questo comando:

actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
  --output=user-cluster-anthos-config.yaml

Distribuisci user-cluster-anthos-config.yaml agli utenti del cluster utente.

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

actl auth login --login-config=user-cluster-anthos-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./user-cluster-oidc-kubeconfig

Sostituisci USER_CLUSTER_NAME con il nome del cluster utente come indicato nella Console di amministrazione. --kubeconfig=user-cluster-oidc-kubeconfig è il nome del file Kubeconfig di output.

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

Usa la nuova kubeconfig con kubectl come segue:

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

Autenticazione con SSO Google

Tieni presente che il servizio SSO di Google non è disponibile in modalità isolata e questa sezione è solo a scopo dimostrativo e di test. Se vuoi utilizzare il servizio SSO di Google, sia il cluster che i browser devono essere in grado di contattare i server SSO di Google. I server SSO di Google non devono essere in grado di contattare i cluster utente.

1. Accedi a Google Cloud Console e seleziona un progetto valido.
2. Accedi alla sezione "API e servizi > Schermata consenso OAuth".
3. Creare una nuova schermata di consenso OAuth. Queste informazioni vengono generalmente mostrate agli utenti.
   1. Imposta la home page dell'applicazione sull'URL dell'amministratore.
4. Nella sezione API e servizi & gt; Credenziali:
   1. Fai clic su Crea credenziali.
   2. Crea un nuovo ID client OAuth.
   3. Imposta il tipo di applicazione su Applicazione web.
   4. Scegli un nome pertinente.
   5. Per le origini JavaScript, imposta https://anthos.example.com (supponendo che https://anthos.example.com sia il tuo nome di dominio per il Centro di gestione).
   6. Per gli URI di reindirizzamento autorizzati, imposta:
      • https://anthos.example.com/_gcp_anthos_oidc_callback
      • http://localhost:9879/callback
5. Copia il ClientID e il client secret nella configurazione di amministrazione UI.
6. Imposta l'URL del provider OIDC su https://accounts.google.com.
7. Imposta Username Claim su email e Scopes su openid email.
8. Imposta parametri aggiuntivi su prompt=consent,access_type=offline. In caso contrario, non potrai accedere con il server API di Kubernetes.
9. Aggiungi l'elenco iniziale di indirizzi email degli utenti (separati da virgole) per ottenere le autorizzazioni di amministratore della piattaforma.
10. Fai clic su Save.

Audit logging

Il controllo Kubernetes è abilitato per la modalità privata di Anthos, fornendo un approccio che consente di controllare l'accesso amministrativo e le azioni sulla piattaforma.

Al momento non è possibile personalizzare l'audit logging per parametri quali tempo di conservazione, frequenza di aggiornamento o dimensioni del blocco. Il livello di controllo è Metadata, che registra i metadati della richiesta (utente richiedente, timestamp, risorsa, verbo) ma non il corpo della richiesta o della risposta.

Nota: vengono esportati sia l'audit logging dell'amministratore che quello dell'audit cluster del cluster utente.

L'audit logging è abilitato in modalità privata di Anthos per impostazione predefinita. Consulta Logging e monitoraggio per i passaggi dettagliati su come accedere agli audit log.

Nota: attualmente questa non è una posizione protetta in cui archiviare i log di controllo. Le persone con un numero sufficiente di autorizzazioni k8s (ad es. IO) possono eliminare o manomettere gli audit log.