Sdílet prostřednictvím


Použití jednotného přihlašování služby Active Directory k zabezpečenému připojení k serveru rozhraní API Kubernetes v AKS povoleném službou Azure Arc

Platí pro: AKS v Azure Stack HCI 22H2, AKS na Windows Serveru

Zabezpečené připojení k serveru rozhraní API Kubernetes v AKS povoleném službou Arc můžete vytvořit pomocí přihlašovacích údajů jednotného přihlašování (SSO) služby Active Directory (AD).

Přehled služby AD v AKS povoleném službou Arc

Bez ověřování službou Active Directory musíte při připojení k serveru kubectl rozhraní API pomocí příkazu spoléhat na soubor kubeconfig založený na certifikátu. Soubor kubeconfig obsahuje tajné kódy, jako jsou privátní klíče a certifikáty, které je potřeba pečlivě distribuovat, což může být významné bezpečnostní riziko.

Jako alternativu k použití kubeconfig založeného na certifikátech můžete použít přihlašovací údaje jednotného přihlašování služby AD jako bezpečný způsob připojení k serveru rozhraní API. Integrace AD s AKS Arc umožňuje uživatelům na počítači připojeném k doméně s Windows připojit se k serveru rozhraní API pomocí kubectl svých přihlašovacích údajů pro jednotné přihlašování. Tím se odebere potřeba spravovat a distribuovat soubory kubeconfig založené na certifikátech, které obsahují privátní klíče.

Integrace AD používá ad kubeconfig, který se liší od souborů kubeconfig založených na certifikátech a neobsahuje žádné tajné kódy. Soubor kubeconfig založený na certifikátu se ale dá použít pro účely zálohování, jako je například řešení potíží s připojením pomocí přihlašovacích údajů služby Active Directory.

Další výhodou zabezpečení s integrací AD je, že uživatelé a skupiny se ukládají jako identifikátory zabezpečení (SID). Na rozdíl od názvů skupin jsou identifikátory SID neměnné a jedinečné a proto neexistují žádné konflikty pojmenování.

Poznámka:

Připojení jednotného přihlašování k AD se podporuje jenom pro clustery úloh.

Poznámka:

Použití vnořených skupin AD (vytvoření skupiny AD v jiné skupině AD) není podporováno.

Tento článek vás provede postupem nastavení služby Active Directory jako zprostředkovatele identity a povolení jednotného přihlašování prostřednictvím kubectl:

  • Vytvořte účet AD pro server rozhraní API a pak vytvořte soubor keytab přidružený k účtu. Viz Vytvoření ověřování AD pomocí souboru keytab k vytvoření účtu AD a vygenerování souboru keytab.
  • Pomocí souboru keytab nainstalujte ověřování AD v clusteru Kubernetes. V rámci tohoto kroku se automaticky vytvoří výchozí konfigurace řízení přístupu na základě role (RBAC).
  • Při vytváření nebo úpravě konfigurací RBAC převeďte názvy skupin na identifikátory SID a naopak. Pokyny najdete v tématu vytvoření a aktualizace vazby role skupiny AD.

Než začnete

Před zahájením procesu konfigurace přihlašovacích údajů jednotného přihlašování služby Active Directory byste měli zajistit, abyste měli k dispozici následující položky:

  • Nainstaluje se nejnovější modul PowerShellu Aks-Hci. Pokud ho potřebujete nainstalovat, přečtěte si informace o stažení a instalaci modulu AksHci PowerShellu.

  • Hostitel AKS je nainstalovaný a nakonfigurovaný. Pokud potřebujete nainstalovat hostitele, nakonfigurujte nasazení podle kroků.

  • Soubor keytab je k dispozici pro použití. Pokud není k dispozici, postupujte podle pokynů k vytvoření účtu AD serveru API a souboru keytab.

    Poznámka:

    Měli byste vygenerovat soubor keytab pro konkrétní hlavní název služby (SPN) a tento hlavní název služby (SPN) musí odpovídat účtu AD serveru rozhraní API pro cluster úloh. Musíte také zajistit, aby se stejný hlavní název služby (SPN) používal během procesu ověřování AD. Soubor keytab by měl mít název current.keytab.

  • Pro každý cluster úloh AKS je k dispozici jeden účet AD serveru rozhraní API.

  • Klientský počítač musí být počítač připojený k doméně Windows.

Vytvoření ověřování AD pomocí souboru keytab

Krok 1: Vytvoření clusteru úloh a povolení ověřování AD

Před instalací ověřování AD musíte nejprve vytvořit cluster úloh AKS a povolit doplněk ověřování AD v clusteru. Pokud při vytváření nového clusteru ověřování AD nepovolíte, nemůžete ho později povolit.

Otevřete PowerShell jako správce a spusťte následující příkaz pomocí -enableADAuth parametru New-AksHciCluster příkazu:

New-AksHciCluster -name mynewcluster1 -enableADAuth

Pro každý cluster úloh se ujistěte, že je k dispozici jeden účet AD serveru API.

Informace o vytvoření clusteru úloh najdete v tématu Vytváření clusterů Kubernetes pomocí Prostředí Windows PowerShell.

Krok 2: Instalace ověřování AD

Než budete moct nainstalovat ověřování AD, musí být cluster úloh nainstalovaný a v clusteru je povolené ověřování AD. Pokud chcete nainstalovat ověřování AD, použijte jednu z následujících možností.

Možnost 1

V případě clusteru Azure Stack HCI nebo Windows Serveru připojeného k doméně otevřete PowerShell jako správce a spusťte následující příkaz:

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

Poznámka:

Pro SPN k8s/apiserver@CONTOSO.compoužití formátu SPN k8s/apiserver@<realm name>. Při prvním pokusu zadejte <realm name> velká písmena. Pokud ale máte problémy s velkými písmeny, vytvořte hlavní název služby (SPN) s malými písmeny. Protokol Kerberos rozlišují malá a velká písmena.

Možnost 2

Pokud hostitel clusteru není připojený k doméně, použijte uživatelské jméno správce nebo název skupiny ve formátu SID, jak je znázorněno v následujícím příkladu.

Uživatel s rolí správce:

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

Skupina pro správu:

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

Identifikátor SID pro uživatelský účet najdete v tématu Určení identifikátoru zabezpečení uživatele nebo skupiny.

Než budete pokračovat k dalším krokům, poznamenejte si následující položky:

  • Ujistěte se, že soubor keytab má název current.keytab.
  • Nahraďte hlavní název služby (SPN), který odpovídá vašemu prostředí.
  • Parametr -adminGroup vytvoří odpovídající vazbu role pro zadanou skupinu AD s oprávněními správce clusteru. Nahraďte contoso\bob (jak je znázorněno v možnosti 1 výše) skupinou AD nebo uživatelem, který odpovídá vašemu prostředí.

Krok 3: Otestování souboru webhooku a klávesové zkratky AD

Ujistěte se, že webhook AD běží na serveru rozhraní API a soubor keytab je uložený jako tajný klíč Kubernetes. Pokud chcete získat soubor kubeconfig založený na certifikátech pro cluster úloh, postupujte takto:

  1. Pomocí následujícího příkazu získejte soubor kubeconfig založený na certifikátu. Pomocí souboru kubeconfig se připojte ke clusteru jako místní hostitel:

    Get-AksHciCredential -name mynewcluster1
    
  2. Spusťte kubectl na serveru, ke kterému jste se připojili (pomocí souboru kubeconfig založeného na certifikátu, který jste vytvořili dříve) a zkontrolujte nasazení webhooku AD, abyste měli jistotu, že je ve formátu ad-auth-webhook-xxxx:

    kubectl get pods -n=kube-system
    
  3. Spuštěním zkontrolujte kubectl , jestli je soubor keytab nasazený jako tajný klíč a je uvedený jako tajný klíč Kubernetes:

    kubectl get secrets -n=kube-system
    

Krok 4: Vytvoření souboru kubeconfig služby AD

Po úspěšném nasazení webhooku a klávesové zkratky AD vytvořte soubor kubeconfig služby AD. Po vytvoření souboru zkopírujte soubor kubeconfig služby AD do klientského počítače a použijte ho k ověření na serveru rozhraní API. Na rozdíl od souboru kubeconfig založeného na certifikátu není ad kubeconfig tajným kódem a je bezpečné kopírovat jako prostý text.

Otevřete PowerShell jako správce a spusťte následující příkaz:

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

Krok 5: Kopírování kubeconfig a dalších souborů do klientského počítače

Z clusteru úloh AKS byste měli zkopírovat následující tři soubory do klientského počítače:

  • Zkopírujte soubor KUBeconfig služby AD vytvořený v předchozím kroku do $env:USERPROFILE.kube\config.

  • Vytvořte cestu ke složce c:\adsso a zkopírujte následující soubory z clusteru úloh AKS do klientského počítače:

    • Kubectl.exe v části $env:ProgramFiles\AksHci do c:\adsso.
    • Kubectl-adsso.exe v části $env:ProgramFiles\AksHci na c:\adsso.

    Poznámka:

    Při spuštění Get-AksHciCredential rutiny se na serveru vygeneruje soubor adsso.exe.

Krok 6: Připojení k serveru rozhraní API z klientského počítače

Po dokončení předchozích kroků se pomocí přihlašovacích údajů jednotného přihlašování přihlaste ke svému klientskému počítači připojenému k doméně Windows. Otevřete PowerShell a pak se pokuste o přístup k serveru rozhraní API pomocí kubectl. Pokud se operace úspěšně dokončí, správně jste nastavili jednotné přihlašování ad.

Vytvoření a aktualizace vazby role skupiny AD

Jak je uvedeno v kroku 2, vytvoří se výchozí vazba role s oprávněními správce clusteru pro uživatele nebo skupinu, která byla poskytována během instalace. Vazba role v Kubernetes definuje zásady přístupu pro skupiny AD. Tento krok popisuje, jak pomocí RBAC vytvořit nové vazby rolí skupiny AD v Kubernetes a upravit existující vazby rolí. Správce clusteru může například chtít uživatelům udělit další oprávnění pomocí skupin AD (což proces zefektivňuje). Další informace o RBAC najdete v tématu Použití autorizace RBAC.

Když vytváříte nebo upravujete jiné položky RBAC skupiny AD, měl by mít název subjektu předponu názvu microsoft:activedirectory:CONTOSO\group . Všimněte si, že názvy musí obsahovat název domény a předponu uzavřenou dvojitými uvozovkami.

Zde jsou dva příklady:

Příklad 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" 

Příklad 2

Následující příklad ukazuje, jak vytvořit vlastní roli a vazbu role pro obor názvů se skupinou AD. V tomto příkladu SREGroup je již existující skupina ve službě Contoso Active Directory. Když se uživatelé přidají do skupiny AD, okamžitě jim udělíte oprávnění.

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" 

Před použitím souboru YAML by se názvy skupin a uživatelů měly vždy převést na identifikátory SID pomocí příkazu:

kubectl-adsso nametosid <rbac.yml>

Podobně můžete identifikátor SID před provedením změn převést na uživatelsky přívětivý název skupiny, abyste mohli aktualizovat existující RBAC. K převodu identifikátoru SID použijte příkaz:

kubectl-adsso sidtoname <rbac.yml>

Změna hesla účtu AD přidruženého k účtu serveru ROZHRANÍ API

Když se změní heslo pro účet serveru rozhraní API, musíte doplněk pro ověřování AD odinstalovat a znovu nainstalovat pomocí aktualizovaných aktuálních a předchozích klávesových tabulek.

Pokaždé, když změníte heslo, musíte aktuální klíčtab (current.keytab) přejmenovat na previous.keytab. Pak se ujistěte, že nové heslo pojmenujete current.keytab.

Důležité

Soubory musí mít název current.keytab a previous.keytab. Na stávající vazby rolí tato změna nemá vliv.

Odinstalace a přeinstalace ověřování AD

Při změně účtu pro server rozhraní API, při aktualizaci hesla nebo při řešení potíží se selháním může být vhodné přeinstalovat jednotné přihlašování ad.

Pokud chcete odinstalovat ověřování AD, otevřete PowerShell jako správce a spusťte následující příkaz:

Uninstall-AksHciAdAuth -name mynewcluster1

Pokud chcete přeinstalovat ověřování AD, otevřete PowerShell jako správce a spusťte následující příkaz:

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

Poznámka:

Aby nedocházelo k výpadkům, pokud klienti mají lístky uložené v mezipaměti, -previousKeytab je parametr vyžadován pouze při změně hesla.

Vytvoření účtu AD serveru rozhraní API a souboru keytab

Při vytváření účtu AD a souboru keytab jsou zapojeny dva kroky. Nejprve vytvořte nový účet AD nebo uživatele pro server rozhraní API s hlavním názvem služby (SPN) a za druhé vytvořte soubor s klíči pro účet AD.

Krok 1: Vytvoření nového účtu AD nebo uživatele pro server rozhraní API

Pomocí příkazu New-ADUser PowerShell vytvořte nový účet AD nebo uživatele s hlavním název služby (SPN). Tady je příklad:

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

Krok 2: Vytvoření souboru keytab pro účet AD

K vytvoření souboru keytab použijte příkaz ktpass Windows.

Tady je příklad použití ktpassu:

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

Poznámka:

Pokud se zobrazí chyba DsCrackNames vrácená 0x2 v položce názvu, ujistěte se, že parametr pro /mapuser je ve formátu mapuser DOMAIN\user, kde DOMAIN je výstup echo %userdomain%.

Určení identifikátoru zabezpečení uživatele nebo skupiny

Pomocí jedné z následujících dvou možností vyhledejte identifikátor SID pro váš účet nebo jiné účty:

  • Pokud chcete najít identifikátor SID přidružený k vašemu účtu, na příkazovém řádku domovského adresáře zadejte následující příkaz:

    whoami /user
    
  • Pokud chcete najít identifikátor SID přidružený k jinému účtu, otevřete PowerShell jako správce a spusťte následující příkaz:

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

Řešení potíží s certifikáty

Webhook a server rozhraní API používají certifikáty k vzájemnému ověření připojení TLS. Platnost tohoto certifikátu vyprší za 500 dnů. Pokud chcete ověřit, že platnost certifikátu vypršela, prohlédněte si protokoly z kontejneru ad-auth-webhook :

kubectl logs ad-auth-webhook-xxx

Pokud se zobrazí chyby ověření certifikátu, proveďte kroky odinstalace a přeinstalace webhooku a získání nových certifikátů.

Osvědčené postupy a vyčištění

  • Pro každý cluster použijte jedinečný účet.
  • Nepoužívejte heslo pro účet serveru rozhraní API napříč clustery.
  • Jakmile vytvoříte cluster, odstraňte místní kopii souboru keytab a ověřte, že přihlašovací údaje jednotného přihlašování fungují.
  • Odstraňte uživatele služby Active Directory, který byl vytvořen pro server rozhraní API. Další informace naleznete v tématu Remove-ADUser.

Další kroky

V tomto návodu jste zjistili, jak nakonfigurovat ověřování AD pro bezpečné připojení k serveru rozhraní API pomocí přihlašovacích údajů jednotného přihlašování. Dále můžete: