Usare l'accesso Single Sign-On di Active Directory per la connessione sicura al server API Kubernetes nel servizio Azure Kubernetes abilitato da Azure Arc

  • Articolo

Si applica a: servizio Azure Kubernetes in Azure Stack HCI 22H2, servizio Azure Kubernetes in Windows Server

È possibile creare una connessione sicura al server API Kubernetes nel servizio Azure Kubernetes abilitato da Arc usando le credenziali di Single Sign-On (AD) di Active Directory (AD).

Panoramica di Active Directory nel servizio Azure Kubernetes abilitato da Arc

Senza l'autenticazione di Active Directory, gli utenti devono basarsi su un file kubeconfig basato su certificati durante la connessione al server API tramite il kubectl comando . Il file kubeconfig contiene segreti come chiavi private e certificati che devono essere distribuiti con attenzione, che possono essere un rischio significativo per la sicurezza.

In alternativa all'uso di kubeconfig basato su certificati, è possibile usare le credenziali SSO di AD come modo sicuro per connettersi al server API. L'integrazione di ACTIVE Directory con AKS Arc consente agli utenti in un computer aggiunto a un dominio Windows di connettersi al server API tramite kubectl le credenziali SSO. In questo modo viene rimossa la necessità di gestire e distribuire file kubeconfig basati su certificati che contengono chiavi private.

L'integrazione di ACTIVE Directory usa AD kubeconfig, che è distinto dai file kubeconfig basati su certificati e non contiene segreti. Tuttavia, il file kubeconfig basato su certificato può essere usato a scopo di backup, ad esempio la risoluzione dei problemi, in caso di problemi di connessione con le credenziali di Active Directory.

Un altro vantaggio di sicurezza con l'integrazione di Active Directory è che gli utenti e i gruppi vengono archiviati come identificatori di sicurezza (SID). A differenza dei nomi dei gruppi, i SID non sono modificabili e univoci e pertanto non presentano conflitti di denominazione.

Nota

Attualmente, la connettività SSO di AD è supportata solo per i cluster del carico di lavoro.

Questo articolo illustra la procedura seguente per configurare Active Directory come provider di identità e per abilitare l'accesso SSO tramite kubectl:

  • Create l'account AD per il server API e quindi creare il file keytab associato all'account. Vedere Create autenticazione di AD usando il file keytab per creare l'account AD e generare il file keytab.
  • Usare il file keytab per installare l'autenticazione di ACTIVE Directory nel cluster Kubernetes. Come parte di questo passaggio, viene creata automaticamente una configurazione del controllo degli accessi in base al ruolo predefinita.
  • Convertire i nomi dei gruppi in SID e viceversa durante la creazione o la modifica di configurazioni del controllo degli accessi in base al ruolo, vedere Creare e aggiornare l'associazione di ruoli del gruppo di Active Directory per istruzioni.

Prima di iniziare

Prima di avviare il processo di configurazione delle credenziali SSO di Active Directory, è necessario assicurarsi di disporre degli elementi seguenti disponibili:

  • Viene installato il modulo Azure Kubernetes-Hci PowerShell più recente. Se è necessario installarlo, vedere scaricare e installare il modulo AksHci PowerShell.

  • L'host del servizio Azure Kubernetes viene installato e configurato. Se è necessario installare l'host, seguire la procedura per configurare la distribuzione.

  • Il file keytab è disponibile per l'uso. Se non è disponibile, seguire la procedura per creare l'account AD del server API e il file keytab.

    Nota

    È necessario generare il file keytab per un nome dell'entità servizio specifico (SPN) e questo NOME SPN deve corrispondere all'account AD del server API per il cluster del carico di lavoro. È anche necessario assicurarsi che lo stesso NOME SPN venga usato in tutto il processo di autenticazione di ACTIVE Directory. Il file keytab deve essere denominato current.keytab.

  • Per ogni cluster del carico di lavoro del servizio Azure Kubernetes è disponibile un account AD del server API.

  • Il computer client deve essere un computer aggiunto a un dominio Windows.

Create autenticazione di ACTIVE Directory usando il file keytab

Passaggio 1: Create il cluster del carico di lavoro e abilitare l'autenticazione di ACTIVE Directory

Prima di installare l'autenticazione di Active Directory, è necessario creare un cluster del carico di lavoro del servizio Azure Kubernetes e abilitare il componente aggiuntivo di autenticazione di Active Directory nel cluster. Se non si abilita l'autenticazione di Active Directory quando si crea il nuovo cluster, non è possibile abilitarla in un secondo momento.

Aprire PowerShell come amministratore ed eseguire quanto segue usando il -enableADAuth parametro del New-AksHciCluster comando :

New-AksHciCluster -name mynewcluster1 -enableADAuth

Per ogni cluster del carico di lavoro, assicurarsi che sia disponibile un account AD del server API.

Per informazioni sulla creazione del cluster del carico di lavoro, vedere Create cluster Kubernetes usando Windows PowerShell.

Passaggio 2: Installare l'autenticazione di ACTIVE Directory

Prima di poter installare l'autenticazione di Active Directory, è necessario installare il cluster del carico di lavoro e abilitare l'autenticazione di ACTIVE Directory nel cluster. Per installare l'autenticazione di Active Directory, usare una delle opzioni seguenti.

Opzione 1

Per un cluster Azure Stack HCI o Windows Server aggiunto a un dominio, aprire PowerShell come amministratore ed eseguire il comando seguente:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUser contoso\bob

Nota

Per SPN k8s/apiserver@CONTOSO.com, usare il formato SPN k8s/apiserver@<realm name>. Al primo tentativo, specificare <realm name> in lettere maiuscole. Tuttavia, se si verificano problemi con lettere maiuscole, creare il nome SPN con lettere minuscole. Kerberos fa distinzione tra maiuscole e minuscole.

Opzione 2

Se l'host del cluster non è aggiunto a un dominio, usare il nome utente amministratore o il nome del gruppo in formato SID, come illustrato nell'esempio seguente.

Se si usa un utente amministratore:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUserSID <User SID>

Se si usa un gruppo di amministrazione:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminGroupSID <Group SID>

Per trovare il SID per l'account utente, vedere Determinare l'identificatore di sicurezza dell'utente o del gruppo.

Prima di procedere ai passaggi successivi, prendere nota degli elementi seguenti:

  • Assicurarsi che il file keytab sia denominato current.keytab.
  • Sostituire il nome SPN corrispondente all'ambiente.
  • Il -adminGroup parametro crea un'associazione di ruolo corrispondente per il gruppo di Active Directory specificato con privilegi di amministratore del cluster. Sostituire contoso\bob (come illustrato nell'opzione 1, sopra) con il gruppo di Active Directory o l'utente corrispondente all'ambiente.

Passaggio 3: Testare il webhook di Active Directory e il file keytab

Assicurarsi che il webhook di Active Directory sia in esecuzione nel server API e che il file keytab sia archiviato come segreto Kubernetes. Per ottenere il file kubeconfig basato su certificato per il cluster del carico di lavoro, seguire questa procedura:

  1. Ottenere un file kubeconfig basato su certificato usando il comando seguente. Usare il file kubeconfig per connettersi al cluster come host locale:

    Get-AksHciCredential -name mynewcluster1

  2. Eseguire kubectl nel server a cui si è connessi (usando il file kubeconfig basato su certificato creato in precedenza) e quindi controllare la distribuzione del webhook di Active Directory per assicurarsi che sia nel formato ad-auth-webhook-xxxx:

    kubectl get pods -n=kube-system

  3. Eseguire kubectl per verificare che il file keytab sia distribuito come segreto ed è elencato come segreto Kubernetes:

    kubectl get secrets -n=kube-system

Passaggio 4: Create il file kubeconfig di AD

Dopo aver distribuito correttamente il webhook e il keytab di Active Directory, creare il file kubeconfig di AD. Dopo aver creato il file, copiare il file kubeconfig di AD nel computer client e usarlo per eseguire l'autenticazione nel server API. A differenza del file kubeconfig basato su certificato, AD kubeconfig non è un segreto ed è sicuro da copiare come testo normale.

A tale scopo, aprire PowerShell come amministratori ed eseguire il comando seguente:

Get-AksHciCredential -name mynewcluster1 -configPath .\AdKubeconfig -adAuth

Passaggio 5: Copiare kubeconfig e altri file nel computer client

Copiare i tre file seguenti dal cluster del carico di lavoro del servizio Azure Kubernetes nel computer client:

  • Copiare il file kubeconfig di AD creato nel passaggio precedente in $env:USERPROFILE.kube\config.

  • Create il percorso della cartella c:\adsso e copiare i file seguenti dal cluster del carico di lavoro del servizio Azure Kubernetes al computer client:

    • Kubectl.exe in $env:ProgramFiles\AksHci a c:\adsso.
    • Kubectl-adsso.exe in $env:ProgramFiles\AksHci a c:\adsso.

    Nota

    Il file adsso.exe viene generato nel server quando si esegue il Get-AksHciCredential cmdlet .

Passaggio 6: Connettersi al server API dal computer client

Dopo aver completato i passaggi precedenti, usare le credenziali SSO per accedere al computer client aggiunto al dominio Windows. Aprire PowerShell e quindi tentare di accedere al server API usando kubectl. Se l'operazione viene completata correttamente, è stato configurato correttamente l'accesso SSO di AD.

Create e aggiornare l'associazione di ruoli del gruppo di Active Directory

Come indicato nel passaggio 2, viene creata un'associazione di ruoli predefinita con privilegi di amministratore del cluster per l'utente e/o il gruppo fornito durante l'installazione. L'associazione di ruoli in Kubernetes definisce i criteri di accesso per i gruppi di Active Directory. Questo passaggio descrive come usare il controllo degli accessi in base al ruolo per creare nuove associazioni di ruolo del gruppo di Active Directory in Kubernetes e per modificare le associazioni di ruolo esistenti. Ad esempio, l'amministratore del cluster può voler concedere privilegi aggiuntivi agli utenti usando i gruppi di Active Directory, che rendono il processo più efficiente. Per altre informazioni sul controllo degli accessi in base al ruolo, vedere Uso dell'autorizzazione di controllo degli accessi in base al ruolo.

Quando si creano o si modificano altre voci di controllo degli accessi in base al ruolo del gruppo di Active Directory, il nome del soggetto deve avere il prefisso microsoft:activedirectory:CONTOSO\group name . Si noti che i nomi devono contenere un nome di dominio e un prefisso racchiusi tra virgolette doppie.

Di seguito sono riportati due esempi:

Esempio 1

apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding 
metadata: 
  name: ad-user-cluster-admin 
roleRef: 
  apiGroup: rbac.authorization.k8s.io 
  kind: ClusterRole 
  name: cluster-admin 
subjects: 
- apiGroup: rbac.authorization.k8s.io 
  kind: User 
  name: "microsoft:activedirectory:CONTOSO\Bob"

Esempio 2

Nell'esempio seguente viene illustrato come creare un ruolo personalizzato e un'associazione di ruoli per uno spazio dei nomi con un gruppo di Active Directory. Nell'esempio SREGroup è un gruppo preesistente in Contoso Active Directory. Quando gli utenti vengono aggiunti al gruppo di Active Directory, vengono concessi immediatamente privilegi.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-full-access
  namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ad-user-cluster-admin
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: "microsoft:activedirectory:CONTOSO\SREGroup"

Prima di applicare il file YAML, i nomi di gruppo e utente devono essere sempre convertiti in SID usando il comando :

kubectl-adsso nametosid <rbac.yml>

Analogamente, per aggiornare un controllo degli accessi in base al ruolo esistente, è possibile convertire il SID in un nome di gruppo descrittivo prima di apportare modifiche. Per convertire il SID, usare il comando :

kubectl-adsso sidtoname <rbac.yml>

Modificare la password dell'account AD associata all'account del server API

Quando la password viene modificata per l'account del server API, è necessario disinstallare il componente aggiuntivo di autenticazione di ACTIVE Directory e reinstallarlo usando le schede chiave correnti e precedenti aggiornate.

Ogni volta che si modifica la password, è necessario rinominare la scheda chiave corrente (current.keytab) in previous.keytab. Assicurarsi quindi di assegnare alla nuova password il nome current.keytab.

Importante

I file devono essere denominati rispettivamente current.keytab e previous.keytab. Le associazioni di ruolo esistenti non sono interessate da questa modifica.

Disinstallare e reinstallare l'autenticazione di Active Directory

È possibile reinstallare l'accesso SSO di AD quando l'account per il server API viene modificato, quando la password viene aggiornata o per risolvere un errore.

Per disinstallare l'autenticazione di ACTIVE Directory, aprire PowerShell come amministratore ed eseguire il comando seguente:

Uninstall-AksHciAdAuth -name mynewcluster1

Per reinstallare l'autenticazione di ACTIVE Directory, aprire PowerShell come amministratore ed eseguire il comando seguente:

Install-AksHciAdAuth -name mynewcluster1 -keytab <.\current.keytab> -previousKeytab <.\previous.keytab> -SPN <service/principal@CONTOSO.COM> -adminUser CONTOSO\Bob

Nota

Per evitare tempi di inattività se i client hanno ticket memorizzati nella cache, il -previousKeytab parametro è necessario solo quando si modifica la password.

Create l'account AD del server API e il file keytab

Per creare l'account AD e il file keytab sono necessari due passaggi. Creare prima di tutto un nuovo account AD/utente per il server API con il nome dell'entità servizio (SPN) e, in secondo luogo, creare un file keytab per l'account AD.

Passaggio 1: Create un nuovo account AD o un nuovo utente per il server API

Usare il comando PowerShell New-ADUser per creare un nuovo account AD/utente con il nome SPN. Ecco un esempio:

New-ADUser -Name apiserver -ServicePrincipalNames k8s/apiserver -AccountPassword (ConvertTo-SecureString "password" -AsPlainText -Force) -KerberosEncryptionType AES128 -Enabled 1

Passaggio 2: Create il file keytab per l'account AD

Per creare il file keytab, usare il comando ktpass di Windows.

Ecco un esempio che usa ktpass:

ktpass /out current.keytab /princ k8s/apiserver@CONTOSO.COM /mapuser contoso\apiserver_acct /crypto all /pass p@$$w0rd /ptype KRB5_NT_PRINCIPAL

Nota

Se viene visualizzato l'errore DsCrackNames restituito 0x2 nella voce del nome, assicurarsi che il parametro per /mapuser sia nel formato mapuser DOMAIN\user, dove DOMAIN è l'output di echo %userdomain%.

Determinare l'identificatore di sicurezza dell'utente o del gruppo

Usare una delle due opzioni seguenti per trovare il SID per l'account o altri account:

  • Per trovare il SID associato all'account, da un prompt dei comandi della home directory digitare il comando seguente:

    whoami /user

  • Per trovare il SID associato a un altro account, aprire PowerShell come amministratore ed eseguire il comando seguente:

    (New-Object System.Security.Principal.NTAccount(<CONTOSO\Bob>)).Translate([System.Security.Principal.SecurityIdentifier]).value

Risolvere i problemi relativi ai certificati

Il webhook e il server API usano certificati per convalidare reciprocamente la connessione TLS. Questo certificato scade tra 500 giorni. Per verificare che il certificato sia scaduto, visualizzare i log da un ad-auth-webhook contenitore:

kubectl logs ad-auth-webhook-xxx

Se vengono visualizzati errori di convalida del certificato, completare i passaggi per disinstallare e reinstallare il webhook e ottenere nuovi certificati.

Procedure consigliate e pulizia

  • Usare un account univoco per ogni cluster.
  • Non riutilizzare la password per l'account del server API tra cluster.
  • Eliminare la copia locale del file keytab non appena si crea il cluster e verificare che le credenziali SSO funzionino.
  • Eliminare l'utente di Active Directory creato per il server API. Per altre informazioni, vedere Remove-ADUser.

Passaggi successivi

In questa guida pratica si è appreso come configurare l'autenticazione di ACTIVE Directory per connettersi in modo sicuro al server API con credenziali SSO. Successivamente, sarà possibile: