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

Artykuł
11/23/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. Agenci ci to między innymi:

Agent chmury: usługa odpowiedzialna za aranżację platformy bazowej.
Agent węzła: usługa, która znajduje się w każdym węźle, który wykonuje rzeczywistą pracę 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, odczytu, aktualizowania i usuwania (CRUD) składników infrastruktury, takich jak maszyny wirtualne, wirtualne interfejsy sieciowe i sieci wirtualne (VNET) w klastrze.

Aby komunikować się z agentem w chmurze, klienci wymagają aprowizacji certyfikatów w celu zabezpieczenia tej komunikacji. Każdy klient wymaga skojarzenia z nim tożsamości, która definiuje reguły kontroli dostępu opartej 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 celu dalszego 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 zapewnienia, że masz dostęp do nowych funkcji, poprawek usterek i aktualności przy użyciu 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 bezobsługową, 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 kubelet.
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 urząd certyfikacji etcd, który podpisuje certyfikaty do uwierzytelniania i autoryzacji replikacji danych między replikami etcd w klastrze.

Front Proxy URZĘDU certyfikacji

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

Aprowizowanie certyfikatów

Aprowizowanie certyfikatów dla obiektu kubelet odbywa się przy użyciu uruchamiania protokołu TLS. W przypadku wszystkich innych certyfikatów użyj klucza opartego na języku YAML i tworzenia certyfikatu.

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

Uwaga

Certyfikaty główne są ważne przez 10 lat. Wszystkie inne certyfikaty inne niż certyfikaty 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
Grupuj
Nazwa DNS
Adres IP

Można notBefore określić czas, aby odwołać tylko certyfikaty wystawione przed określonym znacznikiem czasu. notBefore Jeśli nie zostanie określony czas, 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, upewnij się, że określono notBefore godzinę.

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