Udostępnij za pośrednictwem

Używanie logowania jednokrotnego usługi Active Directory do bezpiecznego połączenia z serwerem interfejsu API Kubernetes w usłudze AKS z obsługą usługi Azure Arc

  • Artykuł

Dotyczy: usługa AKS w usłudze Azure Stack HCI 22H2, AKS w systemie Windows Server

Możesz utworzyć bezpieczne połączenie z serwerem interfejsu API Kubernetes w usłudze AKS z obsługą usługi Arc przy użyciu poświadczeń logowania jednokrotnego usługi Active Directory (AD).

Omówienie usługi AD w usłudze AKS włączonej przez usługę Arc

Bez uwierzytelniania usługi Active Directory należy opierać się na pliku kubeconfig opartym na certyfikatach podczas nawiązywania połączenia z serwerem interfejsu kubectl API za pomocą polecenia . Plik kubeconfig zawiera wpisy tajne, takie jak klucze prywatne i certyfikaty, które muszą być starannie dystrybuowane, co może stanowić poważne zagrożenie bezpieczeństwa.

Alternatywą dla używania narzędzia kubeconfig opartego na certyfikatach jest bezpieczne łączenie się z serwerem interfejsu API przy użyciu poświadczeń logowania jednokrotnego usługi AD. Integracja usługi AD z usługą AKS Arc umożliwia użytkownikom na komputerze przyłączonym do domeny systemu Windows łączenie się z serwerem interfejsu API przy użyciu kubectl poświadczeń logowania jednokrotnego. Eliminuje to konieczność zarządzania plikami kubeconfig opartymi na certyfikatach i dystrybuowania ich, które zawierają klucze prywatne.

Integracja usługi AD używa narzędzia kubeconfig usługi AD, który różni się od plików kubeconfig opartych na certyfikatach i nie zawiera żadnych wpisów tajnych. Jednak plik kubeconfig oparty na certyfikatach może służyć do celów kopii zapasowej, takich jak rozwiązywanie problemów, jeśli występują problemy z nawiązywaniem połączenia przy użyciu poświadczeń usługi Active Directory.

Kolejną korzyścią zabezpieczeń z integracją usługi AD jest to, że użytkownicy i grupy są przechowywane jako identyfikatory zabezpieczeń (SID). W przeciwieństwie do nazw grup identyfikatory SID są niezmienne i unikatowe i dlatego nie stanowią konfliktów nazewnictwa.

Uwaga

Łączność logowania jednokrotnego usługi AD jest obsługiwana tylko w przypadku klastrów obciążeń.

Uwaga

Użycie zagnieżdżonych grup usługi AD (tworzenie grupy usługi AD w innej grupie usługi AD) jest nieobsługiwane.

W tym artykule przedstawiono procedurę konfigurowania usługi Active Directory jako dostawcy tożsamości i włączania logowania jednokrotnego za pośrednictwem usługi kubectl:

  • Utwórz konto usługi AD dla serwera interfejsu API, a następnie utwórz plik tab kluczy skojarzony z kontem. Zobacz Tworzenie uwierzytelniania usługi AD przy użyciu pliku keytab, aby utworzyć konto usługi AD i wygenerować plik tab klucza.
  • Użyj pliku keytab, aby zainstalować uwierzytelnianie usługi AD w klastrze Kubernetes. W ramach tego kroku zostanie automatycznie utworzona domyślna konfiguracja kontroli dostępu na podstawie ról (RBAC).
  • Aby uzyskać instrukcje, przekonwertuj nazwy grup na identyfikatory SID i na odwrót podczas tworzenia lub edytowania konfiguracji RBAC. Aby uzyskać instrukcje, zobacz tworzenie i aktualizowanie powiązania roli grupy usługi AD.

Zanim rozpoczniesz

Przed rozpoczęciem procesu konfigurowania poświadczeń logowania jednokrotnego usługi Active Directory upewnij się, że są dostępne następujące elementy:

  • Zainstalowano najnowszy moduł Aks-Hci programu PowerShell . Jeśli musisz go zainstalować, zobacz pobieranie i instalowanie modułu AksHci programu PowerShell.

  • Host usługi AKS jest zainstalowany i skonfigurowany. Jeśli musisz zainstalować hosta, wykonaj kroki konfigurowania wdrożenia.

  • Plik keytab jest dostępny do użycia. Jeśli nie jest dostępna, wykonaj kroki tworzenia konta usługi AD serwera interfejsu API i pliku tab.

    Uwaga

    Należy wygenerować plik keytab dla określonej nazwy głównej usługi (SPN), a ta nazwa SPN musi odpowiadać kontu usługi AD serwera interfejsu API dla klastra obciążenia. Należy również upewnić się, że ta sama nazwa SPN jest używana w całym procesie uwierzytelniania usługi AD. Plik keytab powinien mieć nazwę current.keytab.

  • Jedno konto usługi AD serwera interfejsu API jest dostępne dla każdego klastra obciążenia usługi AKS.

  • Komputer kliencki musi być komputerem przyłączonym do domeny systemu Windows.

Tworzenie uwierzytelniania usługi AD przy użyciu pliku keytab

Krok 1. Tworzenie klastra obciążeń i włączanie uwierzytelniania usługi AD

Przed zainstalowaniem uwierzytelniania usługi AD należy najpierw utworzyć klaster obciążenia usługi AKS i włączyć dodatek uwierzytelniania usługi AD w klastrze. Jeśli podczas tworzenia nowego klastra nie włączysz uwierzytelniania usługi AD, nie możesz go włączyć później.

Otwórz program PowerShell jako administrator i uruchom następujące polecenie przy użyciu -enableADAuth parametru New-AksHciCluster :

New-AksHciCluster -name mynewcluster1 -enableADAuth

Dla każdego klastra obciążeń upewnij się, że jest dostępne jedno konto usługi AD serwera interfejsu API.

Aby uzyskać informacje na temat tworzenia klastra obciążeń, zobacz Tworzenie klastrów Kubernetes przy użyciu programu Windows PowerShell.

Krok 2. Instalowanie uwierzytelniania usługi AD

Przed zainstalowaniem uwierzytelniania usługi AD należy zainstalować klaster obciążenia i włączyć uwierzytelnianie usługi AD w klastrze. Aby zainstalować uwierzytelnianie usługi AD, użyj jednej z następujących opcji.

Opcja 1

W przypadku klastra lokalnego platformy Azure lub systemu Windows Server przyłączonego do domeny otwórz program PowerShell jako administrator i uruchom następujące polecenie:

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

Uwaga

W przypadku SPN k8s/apiserver@CONTOSO.comprogramu użyj formatu SPN k8s/apiserver@<realm name>. Przy pierwszej próbie określ <realm name> wielkie litery. Jeśli jednak masz problemy z wielkimi literami, utwórz nazwę SPN z małymi literami. W protokole Kerberos jest uwzględniana wielkość liter.

Opcja 2

Jeśli host klastra nie jest przyłączony do domeny, użyj nazwy użytkownika administratora lub nazwy grupy w formacie SID, jak pokazano w poniższym przykładzie.

Administrator:

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

Grupa administracyjna:

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

Aby znaleźć identyfikator SID dla konta użytkownika, zobacz Określanie identyfikatora zabezpieczeń użytkownika lub grupy.

Przed przejściem do następnych kroków zanotuj następujące elementy:

  • Upewnij się, że plik keytab ma nazwę current.keytab.
  • Zastąp nazwę SPN odpowiadającą Twojemu środowisku.
  • Parametr -adminGroup tworzy odpowiednie powiązanie roli dla określonej grupy usługi AD z uprawnieniami administratora klastra. Zastąp contoso\bob element (jak pokazano w opcji 1 powyżej) grupą usługi AD lub użytkownikiem odpowiadającym środowisku.

Krok 3. Testowanie elementu webhook i pliku tab usługi AD

Upewnij się, że element webhook usługi AD jest uruchomiony na serwerze interfejsu API, a plik tab kluczy jest przechowywany jako wpis tajny kubernetes. Aby uzyskać plik kubeconfig oparty na certyfikatach dla klastra obciążenia, wykonaj następujące kroki:

  1. Pobierz plik kubeconfig oparty na certyfikacie przy użyciu następującego polecenia. Użyj pliku kubeconfig, aby nawiązać połączenie z klastrem jako host lokalny:

    Get-AksHciCredential -name mynewcluster1

  2. Uruchom polecenie kubectl na serwerze, z którym nawiązaliśmy połączenie (przy użyciu wcześniej utworzonego pliku kubeconfig opartego na certyfikatach), a następnie sprawdź wdrożenie elementu webhook usługi AD, aby upewnić się, że ma on format ad-auth-webhook-xxxx:

    kubectl get pods -n=kube-system

  3. Uruchom polecenie , kubectl aby sprawdzić, czy plik keytab jest wdrożony jako wpis tajny i jest wyświetlany jako wpis tajny kubernetes:

    kubectl get secrets -n=kube-system

Krok 4. Tworzenie pliku kubeconfig usługi AD

Po pomyślnym wdrożeniu elementu webhook i tab klucza usługi AD utwórz plik kubeconfig usługi AD. Po utworzeniu pliku skopiuj plik kubeconfig usługi AD do komputera klienckiego i użyj go do uwierzytelniania na serwerze interfejsu API. W przeciwieństwie do pliku kubeconfig opartego na certyfikatach usługa AD kubeconfig nie jest wpisem tajnym i jest bezpieczna do skopiowania jako zwykły tekst.

Otwórz program PowerShell jako administrator i uruchom następujące polecenie:

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

Krok 5. Kopiowanie pliku kubeconfig i innych plików na komputer kliencki

Do maszyny klienckiej należy skopiować następujące trzy pliki z klastra obciążeń usługi AKS:

  • Skopiuj plik kubeconfig usługi AD utworzony w poprzednim kroku, aby $env:USERPROFILE.kube\config.

  • Utwórz ścieżkę folderu c:\adsso i skopiuj następujące pliki z klastra obciążeń usługi AKS do maszyny klienckiej:

    • Kubectl.exe w obszarze $env:ProgramFiles\AksHci do c:\adsso.
    • Kubectl-adsso.exe w obszarze $env:ProgramFiles\AksHci do c:\adsso.

    Uwaga

    Plik adsso.exe jest generowany na serwerze podczas uruchamiania Get-AksHciCredential polecenia cmdlet.

Krok 6. Nawiązywanie połączenia z serwerem interfejsu API z komputera klienckiego

Po wykonaniu poprzednich kroków użyj poświadczeń logowania jednokrotnego, aby zalogować się do komputera klienckiego przyłączonego do domeny systemu Windows. Otwórz program PowerShell, a następnie spróbuj uzyskać dostęp do serwera interfejsu API przy użyciu polecenia kubectl. Jeśli operacja zakończy się pomyślnie, poprawnie skonfigurowano logowanie jednokrotne usługi AD.

Tworzenie i aktualizowanie powiązania roli grupy usługi AD

Jak wspomniano w kroku 2, domyślne powiązanie roli z uprawnieniami administratora klastra jest tworzone dla użytkownika i/lub grupy, która została podana podczas instalacji. Powiązanie roli na platformie Kubernetes definiuje zasady dostępu dla grup usługi AD. W tym kroku opisano sposób użycia kontroli dostępu opartej na rolach w celu utworzenia nowych powiązań ról grupy usługi AD na platformie Kubernetes i edytowania istniejących powiązań ról. Na przykład administrator klastra może chcieć przyznać użytkownikom dodatkowe uprawnienia przy użyciu grup usługi AD (co sprawia, że proces jest wydajniejszy). Aby uzyskać więcej informacji na temat kontroli dostępu opartej na rolach, zobacz używanie autoryzacji RBAC.

Podczas tworzenia lub edytowania innych wpisów RBAC grupy usługi AD nazwa podmiotu powinna mieć prefiks nazwy microsoft:activedirectory:CONTOSO\group name . Należy pamiętać, że nazwy muszą zawierać nazwę domeny i prefiks, który jest ujęta w cudzysłowy.

Oto dwa przykłady:

Przykład 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"

Przykład 2

W poniższym przykładzie pokazano, jak utworzyć niestandardową rolę i powiązanie roli dla przestrzeni nazw z grupą usługi AD. W tym przykładzie SREGroup jest wcześniej istniejącą grupą w usłudze Contoso Active Directory. Gdy użytkownicy są dodawani do grupy usługi AD, natychmiast otrzymują uprawnienia.

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"

Przed zastosowaniem pliku YAML nazwy grup i użytkowników powinny być zawsze konwertowane na identyfikatory SID przy użyciu polecenia :

kubectl-adsso nametosid <rbac.yml>

Podobnie w celu zaktualizowania istniejącej kontroli dostępu opartej na rolach można przekonwertować identyfikator SID na przyjazną dla użytkownika nazwę grupy przed wprowadzeniem zmian. Aby przekonwertować identyfikator SID, użyj polecenia :

kubectl-adsso sidtoname <rbac.yml>

Zmienianie hasła konta usługi AD skojarzonego z kontem serwera interfejsu API

Po zmianie hasła dla konta serwera interfejsu API należy odinstalować dodatek uwierzytelniania usługi AD i ponownie zainstalować go przy użyciu zaktualizowanych bieżących i poprzednich kart kluczy.

Za każdym razem, gdy zmienisz hasło, musisz zmienić nazwę bieżącej tab klucza (current.keytab) na previous.keytab. Następnie upewnij się, że nazwa nowego hasła current.keytab.

Ważne

Pliki muszą mieć odpowiednio nazwę current.keytab i previous.keytab. Ta zmiana nie ma wpływu na istniejące powiązania ról.

Odinstalowywanie i ponowne instalowanie uwierzytelniania usługi AD

Możesz ponownie zainstalować logowanie jednokrotne usługi AD po zmianie konta serwera interfejsu API, zaktualizowaniu hasła lub rozwiązaniu problemu z błędem.

Aby odinstalować uwierzytelnianie usługi AD, otwórz program PowerShell jako administrator i uruchom następujące polecenie:

Uninstall-AksHciAdAuth -name mynewcluster1

Aby ponownie zainstalować uwierzytelnianie usługi AD, otwórz program PowerShell jako administrator i uruchom następujące polecenie:

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

Uwaga

Aby uniknąć przestoju, jeśli klienci mają buforowane bilety, -previousKeytab parametr jest wymagany tylko w przypadku zmiany hasła.

Tworzenie konta usługi AD serwera interfejsu API i pliku keytab

Dwa kroki są związane z tworzeniem konta usługi AD i pliku tab keytab. Najpierw utwórz nowe konto/użytkownik usługi AD dla serwera interfejsu API z nazwą główną usługi (SPN), a następnie utwórz plik tab klucza dla konta usługi AD.

Krok 1. Tworzenie nowego konta usługi AD lub użytkownika dla serwera interfejsu API

Użyj polecenia New-ADUser programu PowerShell, aby utworzyć nowe konto usługi AD/użytkownik z nazwą SPN. Oto przykład:

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

Krok 2. Tworzenie pliku tab keytab dla konta usługi AD

Aby utworzyć plik keytab, użyj polecenia ktpass systemu Windows.

Oto przykład użycia narzędzia ktpass:

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

Uwaga

Jeśli w wpisie nazwy zostanie wyświetlony błąd DsCrackNames zwrócony 0x2, upewnij się, że parametr dla /mapuser parametru ma postać mapuser DOMAIN\user, gdzie domena jest wynikiem echo %userdomain%.

Określanie identyfikatora zabezpieczeń użytkownika lub grupy

Użyj jednej z następujących dwóch opcji, aby znaleźć identyfikator SID dla twojego konta lub innych kont:

  • Aby znaleźć identyfikator SID skojarzony z kontem, w wierszu polecenia katalogu macierzystego wpisz następujące polecenie:

    whoami /user

  • Aby znaleźć identyfikator SID skojarzony z innym kontem, otwórz program PowerShell jako administrator i uruchom następujące polecenie:

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

Rozwiązywanie problemów z certyfikatami

Element webhook i serwer interfejsu API używają certyfikatów do wzajemnie weryfikowania połączenia TLS. Ten certyfikat wygasa w ciągu 500 dni. Aby sprawdzić, czy certyfikat wygasł, wyświetl dzienniki z kontenera ad-auth-webhook :

kubectl logs ad-auth-webhook-xxx

Jeśli zostaną wyświetlone błędy weryfikacji certyfikatu, wykonaj kroki odinstalowywania i ponownego instalowania elementu webhook oraz uzyskiwania nowych certyfikatów.

Najlepsze rozwiązania i oczyszczanie

  • Użyj unikatowego konta dla każdego klastra.
  • Nie używaj ponownie hasła dla konta serwera interfejsu API w klastrach.
  • Usuń lokalną kopię pliku keytab zaraz po utworzeniu klastra i sprawdź, czy poświadczenia logowania jednokrotnego działają.
  • Usuń użytkownika usługi Active Directory utworzonego dla serwera interfejsu API. Aby uzyskać więcej informacji, zobacz Remove-ADUser.

Następne kroki

W tym przewodniku z instrukcjami przedstawiono sposób konfigurowania uwierzytelniania usługi AD w celu bezpiecznego nawiązywania połączenia z serwerem interfejsu API przy użyciu poświadczeń logowania jednokrotnego. Następnie możesz wykonać następujące czynności: