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 użytkownicy muszą polegać 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 korzystania z narzędzia kubeconfig opartego na certyfikatach jest użycie poświadczeń logowania jednokrotnego usługi AD jako bezpiecznego sposobu nawiązywania połączenia z serwerem interfejsu API. Integracja usługi AD z usługą AKS Arc umożliwia użytkownikom na komputerze przyłączonym do domeny z systemem 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, dlatego nie stanowią konfliktów nazewnictwa.

Uwaga

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

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

  • Twórca konto usługi AD dla serwera interfejsu API, a następnie utwórz plik keytab skojarzony z kontem. Zobacz Twórca Uwierzytelnianie usługi AD przy użyciu pliku keytab, aby utworzyć konto usługi AD i wygenerować plik keytab.
  • 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 opartej na rolach (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 instalowany i konfigurowany. 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 keytab.

    Uwaga

    Należy wygenerować plik keytab dla określonej głównej nazwy 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 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.

Twórca uwierzytelnianie usługi AD przy użyciu pliku keytab

Krok 1. Twórca klastra obciążenia 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 uwierzytelnianie usługi AD nie zostanie włączone podczas tworzenia nowego klastra, nie będzie można go włączyć później.

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

New-AksHciCluster -name mynewcluster1 -enableADAuth

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

Aby uzyskać informacje na temat tworzenia klastra obciążenia, zobacz Twórca klastry Kubernetes korzystające z 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 azure Stack HCI lub 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.

Jeśli używasz użytkownika administratora:

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

Jeśli używasz grupy administratorów:

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 usługi AD i pliku keytab

Upewnij się, że element webhook usługi AD jest uruchomiony na serwerze interfejsu API, a plik keytab 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 certyfikatach 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 został wdrożony jako wpis tajny i jest wyświetlany jako wpis tajny Kubernetes:

    kubectl get secrets -n=kube-system

Krok 4. Twórca 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 na komputer kliencki 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

Na maszynę kliencką 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 do $env:USERPROFILE.kube\config.

  • Twórca ścieżkę folderu c:\adsso i skopiuj następujące pliki z klastra obciążeń usługi AKS na komputer kliencki:

    • 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 po uruchomieniu 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.

Twórca i zaktualizuj powiązanie 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żywania kontroli dostępu opartej na rolach do tworzenia 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 bardziej wydajny). 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 podwójny cudzysłów.

Poniżej przedstawiono 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 wstępnie istniejącą grupą w usłudze Active Directory Contoso. 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 zmieniasz hasło, musisz zmienić nazwę bieżącej tab (current.keytab) na previous.keytab. Następnie upewnij się, że nazwa nowego hasła to 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ąć przestojów, jeśli klienci mają buforowane bilety, -previousKeytab parametr jest wymagany tylko w przypadku zmiany hasła.

Twórca konta usługi AD serwera interfejsu API i pliku keytab

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

Krok 1. Twórca 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. Twórca pliku 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 echa %userdomain%.

Określanie identyfikatora zabezpieczeń użytkownika lub grupy

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

  • Aby znaleźć identyfikator SID skojarzony z twoim 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 wzajemnego weryfikowania połączenia TLS. Ten certyfikat wygasa za 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: