Omówienie zarządzania certyfikatami w usłudze AKS włączonej przez usługę Azure Arc

Artykuł
01/11/2024

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

Usługa AKS włączona przez usługę Azure Arc używa kombinacji uwierzytelniania opartego na certyfikatach i tokenach w celu zabezpieczenia komunikacji między usługami (lub agentami) odpowiedzialnymi za różne operacje na platformie. Uwierzytelnianie oparte na certyfikatach używa certyfikatu cyfrowego do identyfikowania jednostki (agenta, komputera, użytkownika lub urządzenia) przed udzieleniem dostępu do zasobu.

Agent chmury

Podczas wdrażania usługi AKS włączonej przez usługę Arc usługa AKS instaluje agentów używanych do wykonywania różnych funkcji w klastrze. Ci agenci to m.in.:

Agent chmury: usługa odpowiedzialna za orkiestrację platformy bazowej.
Agent węzła: usługa, która znajduje się w każdym węźle, który wykonuje rzeczywistą pracę podczas tworzenia, usuwania maszyny wirtualnej itp.
Zasobnik systemu zarządzania kluczami (KMS): usługa odpowiedzialna za zarządzanie kluczami.
Inne usługi: operator chmury, menedżer certyfikatów itp.

Usługa agenta w chmurze w usłudze AKS jest odpowiedzialna za organizowanie operacji tworzenia, odczytywania, aktualizowania i usuwania (CRUD) składników infrastruktury, takich jak Virtual Machines (maszyny wirtualne), interfejsy Virtual Network (VNICs) i sieci wirtualne (VNETs) w klastrze.

Aby komunikować się z agentem chmury, klienci wymagają aprowizacji certyfikatów w celu zabezpieczenia tej komunikacji. Każdy klient wymaga skojarzenia tożsamości, która definiuje reguły Access Control oparte na rolach (RBAC) skojarzone z klientem. Każda tożsamość składa się z dwóch jednostek:

Token używany do uwierzytelniania początkowego, który zwraca certyfikat i
Certyfikat uzyskany z powyższego procesu logowania i używany do uwierzytelniania w dowolnej komunikacji.

Każda jednostka jest prawidłowa dla określonego okresu (wartość domyślna to 90 dni), na końcu którego wygasa. W przypadku ciągłego dostępu do agenta w chmurze każdy klient wymaga odnowienia certyfikatu i rotacji tokenu.

Typy certyfikatów

Istnieją dwa typy certyfikatów używanych w usłudze AKS włączone przez usługę Arc:

Certyfikat urzędu certyfikacji agenta chmury: certyfikat używany do podpisywania/weryfikowania certyfikatów klienta. Ten certyfikat jest ważny przez 365 dni (1 rok).
Certyfikaty klienta: certyfikaty wystawione przez certyfikat urzędu certyfikacji agenta chmury dla klientów do uwierzytelniania w agencie w chmurze. Te certyfikaty są zwykle ważne przez 90 dni.

Firma Microsoft zaleca aktualizowanie klastrów w ciągu 60 dni od nowej wersji, nie tylko w celu zapewnienia aktualności wewnętrznych certyfikatów i tokenów, ale także upewnienia się, że uzyskujesz dostęp do nowych funkcji, poprawek błędów i aktualizowania krytycznych poprawek zabezpieczeń. Podczas tych comiesięcznych aktualizacji proces aktualizacji obraca wszelkie tokeny, które nie mogą być obracane automatycznie podczas normalnych operacji klastra. Ważność certyfikatu i tokenu jest resetowany do wartości domyślnej 90 dni od daty aktualizacji klastra.

Bezpieczna komunikacja z certyfikatami w usłudze AKS włączona przez usługę Arc

Certyfikaty służą do tworzenia bezpiecznej komunikacji między składnikami klastra. Usługa AKS zapewnia bezdotykową, wbudowaną aprowizację i zarządzanie certyfikatami dla wbudowanych składników platformy Kubernetes. W tym artykule dowiesz się, jak aprowizować certyfikaty i zarządzać nimi w usłudze AKS włączonej przez usługę Arc.

Certyfikaty i urzędy certyfikacji

Usługa AKS generuje i używa następujących urzędów certyfikacji i certyfikatów.

Urząd certyfikacji klastra

Serwer interfejsu API ma urząd certyfikacji klastra, który podpisuje certyfikaty komunikacji jednokierunkowej z serwera interfejsu API do kubeletusługi .
Każdy z nich kubelet tworzy również żądanie podpisania certyfikatu (CSR), które jest podpisane przez urząd certyfikacji klastra na potrzeby komunikacji z kubelet serwera interfejsu API.
Magazyn wartości klucza etcd ma certyfikat podpisany przez urząd certyfikacji klastra na potrzeby komunikacji z itpd do serwera interfejsu API.

etcd urzędu certyfikacji

Magazyn wartości klucza etcd ma itpd urzędu certyfikacji, który podpisuje certyfikaty do uwierzytelniania i autoryzacji replikacji danych między replikami etcd w klastrze.

Front Proxy CA

Urząd certyfikacji serwera proxy frontonu zabezpiecza komunikację między serwerem interfejsu API a serwerem interfejsu API rozszerzenia.

Aprowizowanie certyfikatów

Aprowizowanie certyfikatów dla elementu kubelet odbywa się przy użyciu uruchamiania protokołu TLS. W przypadku wszystkich innych certyfikatów należy użyć klucza opartego na języku YAML i utworzenia certyfikatu.

Certyfikaty są przechowywane w /etc/kubernetes/pki.
Klucze to RSA 4096, EcdsaCurve: P384

Uwaga

Certyfikaty główne są ważne przez 10 lat. Wszystkie inne certyfikaty inne niż główne są krótkotrwałe i ważne przez cztery dni.

Odnawianie certyfikatu i zarządzanie nim

Certyfikaty inne niż główne są automatycznie odnawiane. Wszystkie certyfikaty płaszczyzny sterowania dla platformy Kubernetes z wyjątkiem następujących certyfikatów są zarządzane:

Certyfikat serwera Kubelet
Certyfikat klienta kubeconfig

Najlepszym rozwiązaniem w zakresie zabezpieczeń jest użycie logowania jednokrotnego usługi Active Directory do uwierzytelniania użytkowników.

Odwołanie certyfikatu

Odwołanie certyfikatu powinno być rzadkie i powinno być wykonywane w momencie odnawiania certyfikatu.

Po uzyskaniu numeru seryjnego certyfikatu, który chcesz odwołać, użyj niestandardowego zasobu Kubernetes do definiowania i utrwalania informacji o odwołaniu. Każdy obiekt odwołania może składać się z co najmniej jednego wpisu odwołania.

Aby wykonać odwołanie, użyj jednego z następujących elementów:

Numer seryjny
Group (Grupa)
Nazwa DNS
Adres IP

Można notBefore określić czas, aby odwołać tylko certyfikaty wystawione przed określonym znacznikiem czasu. Jeśli nie notBefore określono czasu, wszystkie istniejące i przyszłe certyfikaty pasujące do odwołania zostaną odwołane.

Uwaga

Odwołanie certyfikatów kubelet serwera jest obecnie niedostępne.

Jeśli używasz numeru seryjnego podczas odwoływania, możesz użyć Repair-AksHciClusterCerts polecenia programu PowerShell opisanego poniżej, aby uzyskać klaster w stanie roboczym. Jeśli używasz dowolnego z innych pól wymienionych wcześniej, pamiętaj o określeniu notBefore czasu.

apiVersion: certificates.microsoft.com/v1 
kind: RenewRevocation 
metadata: 
  name: my-renew-revocation 
  namespace: kube-system 
spec: 
  description: My list of renew revocations 
  revocations: 
  - description: Revoked certificates by serial number 
    kind: serialnumber 
    notBefore: "2020-04-17T17:22:05Z" 
    serialNumber: 77fdf4b1033b387aaace6ce1c18710c2 
  - description: Revoked certificates by group 
    group: system:nodes 
    kind: Group 
  - description: Revoked certificates by DNS 
    dns: kubernetes.default.svc. 
    kind: DNS 
  - description: Revoked certificates by DNS Suffix 
    dns: .cluster.local 
    kind: DNS 
  - description: Revoked certificates by IP 
    ip: 170.63.128.124 
    kind: IP

Udostępnij za pośrednictwem