Eenmalige aanmelding van Active Directory gebruiken voor een beveiligde verbinding met de Kubernetes API-server in AKS ingeschakeld door Azure Arc
Van toepassing op: AKS op Azure Stack HCI 22H2, AKS op Windows Server
U kunt een beveiligde verbinding maken met uw Kubernetes API-server in AKS ingeschakeld door Arc met behulp van eenmalige aanmeldingsgegevens (SSO) van Active Directory (AD).
Overzicht van AD in AKS ingeschakeld door Arc
Zonder Active Directory-verificatie moet u gebruikmaken van een kubeconfig-bestand op basis van certificaten wanneer u via de opdracht verbinding maakt met de kubectl
API-server. Het kubeconfig-bestand bevat geheimen zoals persoonlijke sleutels en certificaten die zorgvuldig moeten worden gedistribueerd, wat een aanzienlijk beveiligingsrisico kan zijn.
Als alternatief voor het gebruik van kubeconfig op basis van certificaten kunt u AD SSO-referenties gebruiken als een veilige manier om verbinding te maken met de API-server. Met AD-integratie met AKS Arc kunnen gebruikers op een computer die lid is van een Windows-domein verbinding maken met de API-server via kubectl
hun SSO-referenties. Hierdoor hoeft u geen kubeconfig-bestanden op basis van certificaten te beheren en te distribueren die persoonlijke sleutels bevatten.
AD-integratie maakt gebruik van AD kubeconfig, wat verschilt van de kubeconfig-bestanden op basis van certificaten en bevat geen geheimen. Het kubeconfig-bestand op basis van certificaten kan echter worden gebruikt voor back-updoeleinden, zoals het oplossen van problemen, als er problemen zijn met het maken van verbinding met behulp van Active Directory-referenties.
Een ander beveiligingsvoordeel met AD-integratie is dat de gebruikers en groepen worden opgeslagen als beveiligings-id's (SID's). In tegenstelling tot groepsnamen zijn SID's onveranderbaar en uniek en zijn er dus geen naamconflicten.
Notitie
Ad SSO-connectiviteit wordt alleen ondersteund voor workloadclusters.
Notitie
Het gebruik van geneste AD-groepen (het maken van een AD-groep binnen een andere AD-groep) wordt niet ondersteund.
In dit artikel wordt u begeleid bij de stappen voor het instellen van Active Directory als id-provider en het inschakelen van eenmalige aanmelding via kubectl
:
- Maak het AD-account voor de API-server en maak vervolgens het keytab-bestand dat is gekoppeld aan het account. Zie AD-verificatie maken met behulp van het keytab-bestand om het AD-account te maken en het keytab-bestand te genereren.
- Gebruik het keytab-bestand om AD-verificatie te installeren op het Kubernetes-cluster. Als onderdeel van deze stap wordt automatisch een standaard RBAC-configuratie (op rollen gebaseerd toegangsbeheer) gemaakt.
- Converteer groepsnamen naar SID's en vice versa bij het maken of bewerken van RBAC-configuraties. Zie de ad-groepsrolbinding maken en bijwerken voor instructies.
Voordat u begint
Voordat u begint met het configureren van referenties voor eenmalige aanmelding van Active Directory, moet u ervoor zorgen dat u over de volgende items beschikt:
De nieuwste Aks-Hci PowerShell-module is geïnstalleerd. Als u deze wilt installeren, raadpleegt u de AksHci PowerShell-module en installeert u deze.
De AKS-host is geïnstalleerd en geconfigureerd. Als u de host wilt installeren, volgt u de stappen om uw implementatie te configureren.
Het keytab-bestand is beschikbaar voor gebruik. Als deze niet beschikbaar is, volgt u de stappen voor het maken van het AD-account van de API-server en het keytab-bestand.
Notitie
U moet het sleuteltabbestand genereren voor een specifieke SPN (Service Principal Name) en deze SPN moet overeenkomen met het AD-account van de API-server voor het workloadcluster. U moet er ook voor zorgen dat dezelfde SPN wordt gebruikt tijdens het AD-verificatieproces. Het keytab-bestand moet de naam current.keytab hebben.
Er is één AD-account van de API-server beschikbaar voor elk AKS-workloadcluster.
De clientcomputer moet een windows-computer zijn die lid is van een domein.
AD-verificatie maken met behulp van het keytab-bestand
Stap 1: Het workloadcluster maken en AD-verificatie inschakelen
Voordat u AD-verificatie installeert, moet u eerst een AKS-workloadcluster maken en de invoegtoepassing AD-verificatie inschakelen op het cluster. Als u AD-verificatie niet inschakelt wanneer u het nieuwe cluster maakt, kunt u dit later niet inschakelen.
Open PowerShell als beheerder en voer het volgende uit met behulp van de -enableADAuth
parameter van de New-AksHciCluster
opdracht:
New-AksHciCluster -name mynewcluster1 -enableADAuth
Zorg ervoor dat er voor elk workloadcluster één AD-account voor de API-server beschikbaar is.
Zie Kubernetes-clusters maken met Windows PowerShell voor informatie over het maken van het workloadcluster.
Stap 2: AD-verificatie installeren
Voordat u AD-verificatie kunt installeren, moet het workloadcluster worden geïnstalleerd en moet de AD-verificatie zijn ingeschakeld op het cluster. Gebruik een van de volgende opties om AD-verificatie te installeren.
Optie 1
Voor een lokaal Azure- of Windows Server-cluster dat lid is van een domein, opent u PowerShell als beheerder en voert u de volgende opdracht uit:
Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUser contoso\bob
Notitie
Gebruik SPN k8s/apiserver@CONTOSO.com
de notatie SPN k8s/apiserver@<realm name>
voor . Geef <realm name>
bij de eerste poging hoofdletters op. Als u echter problemen hebt met hoofdletters, maakt u de SPN met kleine letters. Kerberos is hoofdlettergevoelig.
Optie 2
Als de clusterhost niet lid is van een domein, gebruikt u de gebruikersnaam of groepsnaam van de beheerder in SID-indeling, zoals wordt weergegeven in het volgende voorbeeld.
Gebruiker met beheerdersrechten:
Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUserSID <User SID>
Beheergroep:
Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminGroupSID <Group SID>
Zie De beveiligings-id van de gebruiker of groep bepalen om de SID voor het gebruikersaccount te vinden.
Noteer de volgende items voordat u verdergaat met de volgende stappen:
- Zorg ervoor dat het keytab-bestand de naam current.keytab heeft.
- Vervang de SPN die overeenkomt met uw omgeving.
- De
-adminGroup
parameter maakt een bijbehorende rolbinding voor de opgegeven AD-groep met clusterbeheerdersbevoegdheden. Vervangcontoso\bob
(zoals weergegeven in optie 1 hierboven) door de AD-groep of gebruiker die overeenkomt met uw omgeving.
Stap 3: Het AD-webhook- en keytab-bestand testen
Zorg ervoor dat de AD-webhook wordt uitgevoerd op de API-server en dat het keytab-bestand is opgeslagen als een Kubernetes-geheim. Voer de volgende stappen uit om het kubeconfig-bestand op basis van certificaten voor het workloadcluster op te halen:
Haal een kubeconfig-bestand op basis van een certificaat op met behulp van de volgende opdracht. Gebruik het kubeconfig-bestand om als lokale host verbinding te maken met het cluster:
Get-AksHciCredential -name mynewcluster1
Voer
kubectl
uit op de server waarmee u verbinding hebt gemaakt (met behulp van het kubeconfig-bestand op basis van certificaten dat u eerder hebt gemaakt) en controleer vervolgens de IMPLEMENTATIE van de AD-webhook om te controleren of deze de indelingad-auth-webhook-xxxx
heeft:kubectl get pods -n=kube-system
Voer
kubectl
deze opdracht uit om te controleren of het keytab-bestand is geïmplementeerd als een geheim en wordt vermeld als een Kubernetes-geheim:kubectl get secrets -n=kube-system
Stap 4: het AD kubeconfig-bestand maken
Zodra de AD-webhook en keytab zijn geïmplementeerd, maakt u het AD kubeconfig-bestand. Nadat het bestand is gemaakt, kopieert u het AD kubeconfig-bestand naar de clientcomputer en gebruikt u het om te verifiëren bij de API-server. In tegenstelling tot het kubeconfig-bestand op basis van certificaten is AD kubeconfig geen geheim en is het veilig om als tekst zonder opmaak te kopiëren.
Open PowerShell als een beheerder en voer de volgende opdracht uit:
Get-AksHciCredential -name mynewcluster1 -configPath .\AdKubeconfig -adAuth
Stap 5: Kubeconfig en andere bestanden kopiëren naar de clientcomputer
Kopieer de volgende drie bestanden van het AKS-workloadcluster naar uw clientcomputer:
Kopieer het AD kubeconfig-bestand dat u in de vorige stap hebt gemaakt om te $env:USERPROFILE.kube\config.
Maak het mappad c:\adsso en kopieer de volgende bestanden van het AKS-workloadcluster naar uw clientcomputer:
- Kubectl.exe onder $env:ProgramFiles\AksHci naar c:\adsso.
- Kubectl-adsso.exe onder $env:ProgramFiles\AksHci naar c:\adsso.
Notitie
Het adsso.exe bestand wordt gegenereerd op de server wanneer u de
Get-AksHciCredential
cmdlet uitvoert.
Stap 6: Verbinding maken met de API-server vanaf de clientcomputer
Nadat u de vorige stappen hebt voltooid, gebruikt u uw SSO-referenties om u aan te melden bij uw Windows-clientcomputer die lid is van een domein. Open PowerShell en probeer vervolgens toegang te krijgen tot de API-server met behulp van kubectl
. Als de bewerking is voltooid, stelt u eenmalige aanmelding van AD correct in.
De AD-groepsrolbinding maken en bijwerken
Zoals vermeld in stap 2, wordt er een standaardrolbinding met clusterbeheerdersbevoegdheden gemaakt voor de gebruiker en/of de groep die is opgegeven tijdens de installatie. Rolbinding in Kubernetes definieert het toegangsbeleid voor AD-groepen. In deze stap wordt beschreven hoe u RBAC gebruikt om nieuwe AD-groepsrolbindingen te maken in Kubernetes en bestaande rolbindingen te bewerken. De clusterbeheerder wil bijvoorbeeld extra bevoegdheden verlenen aan gebruikers met behulp van AD-groepen (waardoor het proces efficiënter wordt). Zie RBAC-autorisatie gebruiken voor meer informatie over RBAC.
Wanneer u andere RBAC-vermeldingen voor AD-groepen maakt of bewerkt, moet de onderwerpnaam het voorvoegsel microsoft:activedirectory:CONTOSO\group name hebben. Houd er rekening mee dat de namen een domeinnaam en een voorvoegsel moeten bevatten dat tussen dubbele aanhalingstekens staat.
Hieronder vindt u twee voorbeelden:
Voorbeeld 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"
Voorbeeld 2
In het volgende voorbeeld ziet u hoe u een aangepaste rol en rolbinding maakt voor een naamruimte met een AD-groep. In het voorbeeld SREGroup
is een bestaande groep in De Active Directory van Contoso. Wanneer gebruikers worden toegevoegd aan de AD-groep, krijgen ze onmiddellijk bevoegdheden.
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"
Voordat u het YAML-bestand toepast, moeten de groeps- en gebruikersnamen altijd worden geconverteerd naar SID's met behulp van de opdracht:
kubectl-adsso nametosid <rbac.yml>
Als u een bestaande RBAC wilt bijwerken, kunt u de SID converteren naar een gebruiksvriendelijke groepsnaam voordat u wijzigingen aanbrengt. Gebruik de opdracht om de SID te converteren:
kubectl-adsso sidtoname <rbac.yml>
Het WACHTWOORD van het AD-account wijzigen dat is gekoppeld aan het API-serveraccount
Wanneer het wachtwoord voor het API-serveraccount wordt gewijzigd, moet u de AD-verificatieinvoegtoepassing verwijderen en opnieuw installeren met behulp van de bijgewerkte huidige en vorige sleuteltabs.
Telkens wanneer u het wachtwoord wijzigt, moet u de naam van de huidige keytab (current.keytab) wijzigen in previous.keytab. Zorg er vervolgens voor dat u het nieuwe wachtwoord current.keytab een naam krijgt.
Belangrijk
De bestanden moeten respectievelijk current.keytab en previous.keytab worden genoemd. De bestaande rolbindingen worden niet beïnvloed door deze wijziging.
AD-verificatie verwijderen en opnieuw installeren
Mogelijk wilt u eenmalige aanmelding van AD opnieuw installeren wanneer het account voor de API-server wordt gewijzigd, wanneer het wachtwoord wordt bijgewerkt of om een fout op te lossen.
Als u AD-verificatie wilt verwijderen, opent u PowerShell als beheerder en voert u de volgende opdracht uit:
Uninstall-AksHciAdAuth -name mynewcluster1
Als u AD-verificatie opnieuw wilt installeren, opent u PowerShell als beheerder en voert u de volgende opdracht uit:
Install-AksHciAdAuth -name mynewcluster1 -keytab <.\current.keytab> -previousKeytab <.\previous.keytab> -SPN <service/principal@CONTOSO.COM> -adminUser CONTOSO\Bob
Notitie
Om downtime te voorkomen als de clients tickets in de cache hebben, is de -previousKeytab
parameter alleen vereist wanneer u het wachtwoord wijzigt.
Het AD-account van de API-server en het keytab-bestand maken
Er zijn twee stappen betrokken bij het maken van het AD-account en het keytab-bestand. Maak eerst een nieuw AD-account/-gebruiker voor de API-server met de SPN (Service Principal Name) en maak ten tweede een keytab-bestand voor het AD-account.
Stap 1: Maak een nieuw AD-account of een nieuwe gebruiker voor de API-server
Gebruik de PowerShell-opdracht New-ADUser om een nieuw AD-account/gebruiker te maken met de SPN. Hier volgt een voorbeeld:
New-ADUser -Name apiserver -ServicePrincipalNames k8s/apiserver -AccountPassword (ConvertTo-SecureString "password" -AsPlainText -Force) -KerberosEncryptionType AES128 -Enabled 1
Stap 2: Het keytab-bestand voor het AD-account maken
Gebruik de opdracht ktpass Windows om het keytab-bestand te maken.
Hier volgt een voorbeeld met behulp van ktpass:
ktpass /out current.keytab /princ k8s/apiserver@CONTOSO.COM /mapuser contoso\apiserver_acct /crypto all /pass p@$$w0rd /ptype KRB5_NT_PRINCIPAL
Notitie
Als u de fout DsCrackNames ziet die is geretourneerd 0x2 in de naamvermelding, controleert u of de parameter /mapuser
in vorm mapuser DOMAIN\user
is, waarbij DOMEIN de uitvoer van echo %userdomain%
is.
De beveiligings-id van de gebruiker of groep bepalen
Gebruik een van de volgende twee opties om de SID voor uw account of andere accounts te vinden:
Als u de SID wilt zoeken die is gekoppeld aan uw account, typt u de volgende opdracht vanaf een opdrachtprompt van uw basismap:
whoami /user
Als u de SID wilt zoeken die is gekoppeld aan een ander account, opent u PowerShell als beheerder en voert u de volgende opdracht uit:
(New-Object System.Security.Principal.NTAccount(<CONTOSO\Bob>)).Translate([System.Security.Principal.SecurityIdentifier]).value
Problemen met certificaten oplossen
De webhook en de API-server gebruiken certificaten om de TLS-verbinding wederzijds te valideren. Dit certificaat verloopt over 500 dagen. Als u wilt controleren of het certificaat is verlopen, bekijkt u de logboeken van een ad-auth-webhook
container:
kubectl logs ad-auth-webhook-xxx
Als u certificaatvalidatiefouten ziet, voert u de stappen uit om de webhook te verwijderen en opnieuw te installeren en nieuwe certificaten op te halen.
Best practices en opschonen
- Gebruik een uniek account voor elk cluster.
- Gebruik het wachtwoord niet opnieuw voor het API-serveraccount in clusters.
- Verwijder de lokale kopie van het keytab-bestand zodra u het cluster maakt en controleer of de referenties voor eenmalige aanmelding werken.
- Verwijder de Active Directory-gebruiker die is gemaakt voor de API-server. Zie Remove-ADUser voor meer informatie.
Volgende stappen
In deze handleiding hebt u geleerd hoe u AD-verificatie configureert om veilig verbinding te maken met de API-server met SSO-referenties. Vervolgens kunt u het volgende doen: