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

  • Článek

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

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

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

Bez ověřování Active Directory musí uživatelé při připojování k serveru rozhraní API pomocí příkazu spoléhat na soubor kubeconfig založený na kubectl certifikátu. Soubor kubeconfig obsahuje tajné klíče, 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í nástroje kubeconfig založeného na certifikátech můžete použít přihlašovací údaje jednotného přihlašování AD jako bezpečný způsob připojení k serveru rozhraní API. Integrace AD se službou AKS Arc umožňuje uživatelům na počítači s Windows připojeném k doméně připojit se k serveru rozhraní API pomocí kubectl svých přihlašovacích údajů pro jednotné přihlašování. Díky tomu není 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íží, pokud dojde k problémům s připojením pomocí přihlašovacích údajů active directory.

Další výhodou zabezpečení integrace AD je, že uživatelé a skupiny jsou uložené jako identifikátory zabezpečení (SID). Na rozdíl od názvů skupin jsou identifikátory SID neměnné a jedinečné, a proto neobsahují konflikty názvů.

Poznámka

V současné době se připojení k jednotnému přihlašování AD podporuje jenom pro clustery úloh.

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

Než začnete

Než začnete s procesem konfigurace přihlašovacích údajů jednotného přihlašování Active Directory, měli byste se ujistit, že máte k dispozici následující položky:

  • Je nainstalovaný nejnovější modul PowerShellu Aks-Hci . Pokud ho potřebujete nainstalovat, přečtěte si článek o stažení a instalaci modulu AksHci PowerShellu.

  • Hostitel AKS je nainstalovaný a nakonfigurovaný. Pokud potřebujete nainstalovat hostitele, postupujte podle pokynů ke konfiguraci nasazení.

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

    Poznámka

    Soubor keytab byste měli vygenerovat pro konkrétní hlavní název služby (SPN) a tento hlavní název služby (SPN) musí odpovídat účtu AD serveru API pro cluster úloh. Musíte také zajistit, aby se stejný hlavní název služby (SPN) používal v celém 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 API.

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

Create ověřování AD pomocí souboru keytab

Krok 1: Create 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 v clusteru doplněk ověřování AD. Pokud při vytváření nového clusteru nepovolíte ověřování AD, nebudete ho moct později povolit.

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

New-AksHciCluster -name mynewcluster1 -enableADAuth

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

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

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

Než budete moct nainstalovat ověřování AD, musí být nainstalovaný cluster úloh a v clusteru musí být 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žijte formát SPN k8s/apiserver@<realm name>. Při prvním pokusu zadejte <realm name> hodnotu velkými písmeny. 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šuje velká a malá 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.

Pokud používáte uživatele s rolí správce:

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

Pokud používáte skupinu správců:

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

Identifikátor SID uživatelského účtu 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 má soubor keytab 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 nebo uživatelem AD, který odpovídá vašemu prostředí.

Krok 3: Testování webhooku AD a souboru keytab

Ujistěte se, že webhook AD běží na serveru rozhraní API a že je soubor keytab uložený jako tajný klíč Kubernetes. Pokud chcete získat soubor kubeconfig založený na certifikátu 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 příkaz na serveru, ke kterému jste se připojili (pomocí souboru kubeconfig založeného na certifikátech, který jste vytvořili dříve), a pak zkontrolujte nasazení webhooku AD, abyste se ujistili, že je ve formátu ad-auth-webhook-xxxx:

    kubectl get pods -n=kube-system

  3. Spusťte příkaz kubectl a zkontrolujte, že je soubor keytab nasazený jako tajný kód a že je uvedený jako tajný klíč Kubernetes:

    kubectl get secrets -n=kube-system

Krok 4: Create souboru ad kubeconfig

Po úspěšném nasazení webhooku ad a tabulky klíčů vytvořte soubor AD kubeconfig. 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átech není ad kubeconfig tajný klíč a dá se 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: Zkopírování souboru kubeconfig a dalších souborů do klientského počítače

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

  • Zkopírujte soubor ad kubeconfig vytvořený v předchozím kroku do $env:USERPROFILE.kube\config.

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

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

    Poznámka

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

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 klientskému počítači windows připojenému k doméně. Otevřete PowerShell a pak se pokuste získat přístup k serveru rozhraní API pomocí kubectl. Pokud se operace úspěšně dokončí, nastavili jste jednotné přihlašování AD správně.

Create a aktualizace vazby role skupiny AD

Jak je uvedeno v kroku 2, pro uživatele nebo skupinu, která byla poskytnuta během instalace, se vytvoří výchozí vazba role s oprávněními správce clusteru. Vazba rolí 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ž tento 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 microsoft:activedirectory:CONTOSO\group name . Názvy musí obsahovat název domény a předponu, které jsou uzavřeny dvojitými uvozovkami.

Tady 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, mají okamžitě udělená 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 měla skupina a uživatelská jména vždy převést na identifikátory SID pomocí příkazu:

kubectl-adsso nametosid <rbac.yml>

Podobně, pokud chcete aktualizovat existující RBAC, můžete před provedením změn převést SID na uživatelsky přívětivý název skupiny. Pokud chcete převést SID, použijte příkaz:

kubectl-adsso sidtoname <rbac.yml>

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

Když se změní heslo pro účet serveru API, musíte doplněk ověřování AD odinstalovat a znovu ho přeinstalovat pomocí aktualizovaných aktuálních a předchozích záložek klíčů.

Pokaždé, když změníte heslo, musíte aktuální klávesu (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ázvy current.keytab a previous.keytab v uvedeném pořadí. Stávající vazby rolí nejsou touto změnou ovlivněny.

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

Při změně účtu pro server API, při aktualizaci hesla nebo při řešení potíží s chybou můžete znovu nainstalovat 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

Pokud mají klienti lístky uložené v mezipaměti, aby nedošlo k výpadku, -previousKeytab parametr se vyžaduje pouze při změně hesla.

Create účtu AD serveru API a souboru klíče

Vytvoření účtu AD a souboru tabulky klíčů zahrnuje dva kroky. Nejprve vytvořte nový účet nebo uživatele služby AD pro server rozhraní API s hlavním názvem služby (SPN) a za druhé vytvořte soubor klíče pro účet AD.

Krok 1: Create nový účet ad nebo uživatele pro server rozhraní API

Pomocí příkazu New-ADUser PowerShellu vytvořte nový účet nebo uživatele služby AD s hlavním názvem 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: Create soubor keytab pro účet AD

K vytvoření souboru tabulky klíčů 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 v položce názvu zobrazí chyba DsCrackNames vrácená 0x2, ujistěte se, že parametr pro /mapuser je ve formátu mapuser DOMAIN\user, kde DOMAIN je výstupem echo %userdomain%.

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

K vyhledání identifikátoru SID pro váš účet nebo jiné účty použijte jednu z následujících dvou možností:

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

    whoami /user

  • Pokud chcete najít 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 postup 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 opakovaně heslo pro účet serveru ROZHRANÍ API v clusterech.
  • Jakmile cluster vytvoříte, odstraňte místní kopii souboru tabulky klíčů 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 najdete v tématu Remove-ADUser.

Další kroky

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