Dela via


Använda enkel inloggning i Active Directory för säker anslutning till Kubernetes API-server i AKS som aktiveras av Azure Arc

Gäller för: AKS på Azure Stack HCI 22H2, AKS på Windows Server

Du kan skapa en säker anslutning till kubernetes API-servern i AKS som aktiveras av Arc med hjälp av autentiseringsuppgifter för enkel inloggning med Active Directory (AD).

Översikt över AD i AKS aktiverat av Arc

Utan Active Directory-autentisering måste du förlita dig på en certifikatbaserad kubeconfig-fil när du ansluter till API-servern via kubectl kommandot . Kubeconfig-filen innehåller hemligheter som privata nycklar och certifikat som måste distribueras noggrant, vilket kan vara en betydande säkerhetsrisk.

Som ett alternativ till att använda certifikatbaserad kubeconfig kan du använda AD SSO-autentiseringsuppgifter som ett säkert sätt att ansluta till API-servern. MED AD-integrering med AKS Arc kan användare på en Domänansluten Windows-dator ansluta till API-servern via kubectl sina autentiseringsuppgifter för enkel inloggning. Detta tar bort behovet av att hantera och distribuera certifikatbaserade kubeconfig-filer som innehåller privata nycklar.

AD-integrering använder AD kubeconfig, som skiljer sig från de certifikatbaserade kubeconfig-filerna och inte innehåller några hemligheter. Den certifikatbaserade kubeconfig-filen kan dock användas i säkerhetskopieringssyfte, till exempel felsökning, om det finns problem med att ansluta med Active Directory-autentiseringsuppgifter.

En annan säkerhetsförmån med AD-integrering är att användare och grupper lagras som säkerhetsidentifierare (SID). Till skillnad från gruppnamn är SID:er oföränderliga och unika och ger därför inga namngivningskonflikter.

Kommentar

AD SSO-anslutning stöds endast för arbetsbelastningskluster.

Kommentar

Användningen av kapslade AD-grupper (skapa en AD-grupp i en annan AD-grupp) stöds inte.

Den här artikeln vägleder dig genom stegen för att konfigurera Active Directory som identitetsprovider och aktivera enkel inloggning via kubectl:

Innan du börjar

Innan du börjar konfigurera autentiseringsuppgifter för enkel inloggning med Active Directory bör du se till att du har följande objekt tillgängliga:

  • Den senaste Aks-Hci PowerShell-modulen är installerad. Om du behöver installera den kan du läsa ladda ned och installera AksHci PowerShell-modulen.

  • AKS-värden är installerad och konfigurerad. Om du behöver installera värden följer du stegen för att konfigurera distributionen.

  • Nyckelfliksfilen är tillgänglig att använda. Om den inte är tillgänglig följer du stegen för att skapa API Server AD-kontot och nyckelfliksfilen.

    Kommentar

    Du bör generera nyckelfliksfilen för ett specifikt namn på tjänstens huvudnamn (SPN) och det här SPN:t måste motsvara API-serverns AD-konto för arbetsbelastningsklustret. Du måste också se till att samma SPN används under hela AD-autentiseringsprocessen. Nyckelfliksfilen ska ha namnet current.keytab.

  • Ett API Server AD-konto är tillgängligt för varje AKS-arbetsbelastningskluster.

  • Klientdatorn måste vara en Windows-domänansluten dator.

Skapa AD-autentisering med hjälp av nyckelfliksfilen

Steg 1: Skapa arbetsbelastningsklustret och aktivera AD-autentisering

Innan du installerar AD-autentisering måste du först skapa ett AKS-arbetsbelastningskluster och aktivera AD-autentiseringstillägget i klustret. Om du inte aktiverar AD-autentisering när du skapar det nya klustret kan du inte aktivera det senare.

Öppna PowerShell som administratör och kör följande med hjälp av parametern -enableADAuth för New-AksHciCluster kommandot:

New-AksHciCluster -name mynewcluster1 -enableADAuth

För varje arbetsbelastningskluster kontrollerar du att det finns ett API Server AD-konto tillgängligt.

Information om hur du skapar arbetsbelastningsklustret finns i Skapa Kubernetes-kluster med Windows PowerShell.

Steg 2: Installera AD-autentisering

Innan du kan installera AD-autentisering måste arbetsbelastningsklustret installeras och AD-autentiseringen aktiveras i klustret. Om du vill installera AD-autentisering använder du något av följande alternativ.

Alternativ 1

För ett domänanslutet Azure Local- eller Windows Server-kluster öppnar du PowerShell som administratör och kör följande kommando:

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

Kommentar

För SPN k8s/apiserver@CONTOSO.comanvänder du formatet SPN k8s/apiserver@<realm name>. Vid första försöket anger du <realm name> med versaler. Men om du har problem med versaler skapar du SPN med gemener. Kerberos är skiftlägeskänsligt.

Alternativ 2

Om klustervärden inte är domänansluten använder du administratörsanvändarnamnet eller gruppnamnet i SID-format, som du ser i följande exempel.

Administratörsanvändare:

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

Administratörsgrupp:

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

Information om hur du hittar SID för användarkontot finns i Fastställa användarens eller gruppens säkerhetsidentifierare.

Innan du fortsätter till nästa steg bör du anteckna följande:

  • Kontrollera att nyckelfliksfilen heter current.keytab.
  • Ersätt SPN som motsvarar din miljö.
  • Parametern -adminGroup skapar en motsvarande rollbindning för den angivna AD-gruppen med klusteradministratörsbehörigheter. Ersätt contoso\bob (som visas i alternativ 1 ovan) med den AD-grupp eller användare som motsvarar din miljö.

Steg 3: Testa AD-webhooken och nyckelfliksfilen

Kontrollera att AD-webhooken körs på API-servern och att nyckelfliksfilen lagras som en Kubernetes-hemlighet. Följ dessa steg för att hämta den certifikatbaserade kubeconfig-filen för arbetsbelastningsklustret:

  1. Hämta en certifikatbaserad kubeconfig-fil med hjälp av följande kommando. Använd kubeconfig-filen för att ansluta till klustret som en lokal värd:

    Get-AksHciCredential -name mynewcluster1
    
  2. Kör kubectl på den server som du anslöt till (med den certifikatbaserade kubeconfig-filen som du skapade tidigare) och kontrollera sedan AD webhook-distributionen för att kontrollera att den är i formatet ad-auth-webhook-xxxx:

    kubectl get pods -n=kube-system
    
  3. Kör kubectl för att kontrollera att nyckelfliksfilen distribueras som en hemlighet och visas som en Kubernetes-hemlighet:

    kubectl get secrets -n=kube-system
    

Steg 4: Skapa AD kubeconfig-filen

När AD-webhooken och nyckelfliken har distribuerats skapar du AD kubeconfig-filen. När filen har skapats kopierar du AD kubeconfig-filen till klientdatorn och använder den för att autentisera till API-servern. Till skillnad från den certifikatbaserade kubeconfig-filen är AD kubeconfig inte en hemlighet och är säker att kopiera som oformaterad text.

Öppna PowerShell som administratör och kör följande kommando:

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

Steg 5: Kopiera kubeconfig och andra filer till klientdatorn

Du bör kopiera följande tre filer från AKS-arbetsbelastningsklustret till klientdatorn:

  • Kopiera ad kubeconfig-filen som skapades i föregående steg till $env:USERPROFILE.kube\config.

  • Skapa mappsökvägen c:\adsso och kopiera följande filer från AKS-arbetsbelastningsklustret till klientdatorn:

    • Kubectl.exe under $env:ProgramFiles\AksHci till c:\adsso.
    • Kubectl-adsso.exe under $env:ProgramFiles\AksHci till c:\adsso.

    Kommentar

    Den adsso.exe filen genereras på servern när du kör cmdleten Get-AksHciCredential .

Steg 6: Anslut till API-servern från klientdatorn

När du har slutfört föregående steg använder du dina autentiseringsuppgifter för enkel inloggning för att logga in på din Windows-domänanslutna klientdator. Öppna PowerShell och försök sedan komma åt API-servern med hjälp av kubectl. Om åtgärden har slutförts konfigurerar du AD SSO korrekt.

Skapa och uppdatera AD-grupprollbindningen

Som vi nämnde i steg 2 skapas en standardrollbindning med klusteradministratörsbehörigheter för användaren och/eller gruppen som tillhandahölls under installationen. Rollbindning i Kubernetes definierar åtkomstprinciperna för AD-grupper. Det här steget beskriver hur du använder RBAC för att skapa nya AD-grupprollbindningar i Kubernetes och redigera befintliga rollbindningar. Klusteradministratören kanske till exempel vill bevilja ytterligare behörigheter till användare med hjälp av AD-grupper (vilket gör processen mer effektiv). Mer information om RBAC finns i använda RBAC-auktorisering.

När du skapar eller redigerar andra RBAC-poster för AD-gruppen bör ämnesnamnet ha prefixet microsoft:activedirectory:CONTOSO\group name . Observera att namnen måste innehålla ett domännamn och ett prefix som omges av dubbla citattecken.

Nedan följer två exempel:

Exempel 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" 

Exempel 2

I följande exempel visas hur du skapar en anpassad roll- och rollbindning för ett namnområde med en AD-grupp. I exemplet SREGroup är en befintlig grupp i Contoso Active Directory. När användare läggs till i AD-gruppen beviljas de omedelbart behörigheter.

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" 

Innan du tillämpar YAML-filen ska gruppen och användarnamnen alltid konverteras till SID:er med hjälp av kommandot :

kubectl-adsso nametosid <rbac.yml>

För att uppdatera en befintlig RBAC kan du på samma sätt konvertera SID till ett användarvänligt gruppnamn innan du gör ändringar. Om du vill konvertera SID använder du kommandot:

kubectl-adsso sidtoname <rbac.yml>

Ändra ad-kontolösenordet som är associerat med API-serverkontot

När lösenordet ändras för API-serverkontot måste du avinstallera AD-autentiseringstillägget och installera om det med hjälp av de uppdaterade aktuella och tidigare nyckelflikarna.

Varje gång du ändrar lösenordet måste du byta namn på den aktuella nyckelfliken (current.keytab) till previous.keytab. Kontrollera sedan att du ger det nya lösenordet namnet current.keytab.

Viktigt!

Filerna måste ha namnet current.keytab respektive previous.keytab. De befintliga rollbindningarna påverkas inte av den här ändringen.

Avinstallera och installera om AD-autentisering

Du kanske vill installera om AD SSO när kontot för API-servern ändras, när lösenordet uppdateras eller för att felsöka ett fel.

Om du vill avinstallera AD-autentisering öppnar du PowerShell som administratör och kör följande kommando:

Uninstall-AksHciAdAuth -name mynewcluster1

Om du vill installera om AD-autentisering öppnar du PowerShell som administratör och kör följande kommando:

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

Kommentar

För att undvika stilleståndstid om klienterna har cachelagrade biljetter krävs parametern -previousKeytab endast när du ändrar lösenordet.

Skapa API Server AD-kontot och nyckelfliksfilen

Två steg ingår i skapandet av AD-kontot och nyckelfliksfilen. Skapa först ett nytt AD-konto/användare för API-servern med tjänstens huvudnamn (SPN) och skapa sedan en nyckelfliksfil för AD-kontot.

Steg 1: Skapa ett nytt AD-konto eller en ny användare för API-servern

Använd PowerShell-kommandot New-ADUser för att skapa ett nytt AD-konto/användare med SPN. Här är ett exempel:

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

Steg 2: Skapa nyckelfliksfilen för AD-kontot

Om du vill skapa nyckelfliksfilen använder du kommandot ktpass Windows.

Här är ett exempel med ktpass:

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

Kommentar

Om du ser felet DsCrackNames som returneras 0x2 i namnposten kontrollerar du att parametern för /mapuser är i formatet mapuser DOMAIN\user, där DOMÄN är utdata från eko %userdomain%.

Fastställa säkerhetsidentifieraren för användare eller grupp

Använd något av följande två alternativ för att hitta SID för ditt konto eller andra konton:

  • Om du vill hitta det SID som är associerat med ditt konto skriver du följande kommando från en kommandotolk i hemkatalogen:

    whoami /user
    
  • Om du vill hitta det SID som är associerat med ett annat konto öppnar du PowerShell som administratör och kör följande kommando:

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

Felsöka certifikat

Webhooken och API-servern använder certifikat för att ömsesidigt verifiera TLS-anslutningen. Det här certifikatet upphör att gälla om 500 dagar. Om du vill kontrollera att certifikatet har upphört att gälla kan du visa loggarna från en ad-auth-webhook container:

kubectl logs ad-auth-webhook-xxx

Om du ser certifikatverifieringsfel slutför du stegen för att avinstallera och installera om webhooken och hämta nya certifikat.

Metodtips och rensning

  • Använd ett unikt konto för varje kluster.
  • Återanvänd inte lösenordet för API-serverkontot mellan kluster.
  • Ta bort den lokala kopian av nyckelfliksfilen så snart du skapar klustret och kontrollera att autentiseringsuppgifterna för enkel inloggning fungerar.
  • Ta bort Active Directory-användaren som skapades för API-servern. Mer information finns i Remove-ADUser.

Nästa steg

I den här guiden har du lärt dig hur du konfigurerar AD-autentisering för säker anslutning till API-servern med autentiseringsuppgifter för enkel inloggning. Sedan kan du: