Zabezpečená komunikace pomocí certifikátů

Certifikáty jsou způsob, jak vytvořit zabezpečenou komunikaci mezi komponentami v clusteru. V AKS Azure Stack HCI je pro integrované komponenty Kubernetes k dispozici bezmála bez problémů zřizování a správa certifikátů.

Certifikáty a certifikační autority

AKS na Azure Stack HCI generuje a používá následující certifikáty a certifikační autority:

Certifikační autorita clusteru:

  • Server rozhraní API má certifikační autoritu clusteru, která podepisuje certifikáty pro jednosměnné komunikace ze serveru rozhraní API do kubelet .
  • Každý z nich také vytvoří žádost o podepsání certifikátu (CSR), která je podepsaná certifikační autoritou clusteru pro komunikaci z kubelet kubeletu na server rozhraní API.
  • Úložiště hodnot klíče etcd má certifikát podepsaný certifikační autoritou clusteru pro komunikaci z atd. se serverem rozhraní API.

CERTIFIKAČNÍ autorita etcd:

  • Úložiště hodnot klíče etcd má certifikační autoritu etcd, která podepisuje certifikáty pro ověřování a autorizaci replikace dat mezi replikami etcd v clusteru.

Certifikační autorita front-proxy

  • Ca front-proxy zabezpečuje komunikaci mezi serverem rozhraní API a serverem rozhraní API rozšíření.

Zřizování certifikátů

Zřizování certifikátů pro kubelety se provádí pomocí metody bootstrap protokolu TLS. Pro všechny ostatní certifikáty použijte vytvoření klíče a certifikátu založeného na YAML.

  • Certifikáty se ukládají v /etc/kubernetes/pki.
  • Klíče jsou RSA 4096, EcdsaCurve: P384

Poznámka

Kořenové certifikáty jsou platné 10 let. Všechny ostatní jiné než kořenové certifikáty jsou krátkodobé a platné čtyři dny.

Obnovení a správa certifikátů

Jiné než kořenové certifikáty se automaticky obnovují. Všechny certifikáty řídicí roviny pro Kubernetes se spravují s výjimkou následujících certifikátů:

  • Certifikát serveru Kubelet
  • Klientský certifikát Kubeconfig

Jako osvědčený postup zabezpečení se doporučuje používat pro ověřování uživatelů jednotné přihlašování služby Active Directory.

Odvolání certifikátu

Odvolání by mělo být vzácného incidentu a mělo by se použít v době prodloužení platnosti certifikátu.

Jakmile máte sériové číslo certifikátu, který chcete odvolat, použijte k definování a uchování informací o odvolání vlastní prostředek Kubernetes. Každý objekt odvolání se může skládat z jedné nebo více položek odvolání.

Odvolání lze provést pomocí:

  • Sériové číslo
  • Group (Skupina)
  • Název DNS
  • IP adresa

Je možné zadat čas notBefore, aby se odvolaly pouze certifikáty vydané před určitým časovým razítkem. Pokud není zadaný čas notBefore, odvolané budou všechny existující a budoucí certifikáty odpovídající odvolání.

Poznámka

Odvolání certifikátu kubelet serveru není aktuálně k dispozici.

Pokud bylo odvolání provedeno pomocí sériového čísla, můžete pomocí příkazu PowerShellu popsaného níže dostat Repair-AksHciClusterCerts cluster do funkčního stavu. Pokud bylo odvolání provedeno pomocí jiných polí, nezapomeňte zadat notBefore time (čas ne), abyste mohli cluster obnovit pomocí příkazu .

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 

Řešení potíží a údržba

Informace o protokolování a monitorování najdete v následujících skriptech a dokumentaci:

Obnovení certifikátů pro pracovní uzly

U pracovních uzlů se neúspěšná obnovení certifikátů protokolula podem certificate-renewal-worker. Pokud se prodloužení platnosti certifikátu na pracovním uzlu stále nedaří a platnost certifikátů vyprší, uzel se odebere a na jeho místě se vytvoří nový pracovní uzel.

Tady je příklad zobrazení protokolů pro pod s předponou certificate-renewal-worker:

kubectl.exe --kubeconfig .\testcluster-kubeconfig -n=kube-system get pods 
NAME                                           READY   STATUS             RESTARTS   AGE 
… 
certificate-renewal-worker-6f68k               1/1     Running            0          6d 

Získání protokolů z podu pro prodloužení platnosti certifikátu:

kubectl.exe --kubeconfig .\testcluster-kubeconfig -n=kube-system logs certificate-renewal-worker-6f68k

Obnovení certifikátů pro uzly řídicí roviny

U uzlů řídicí roviny pod certificate-renewal-controller protokoluuje neúspěšná obnovení certifikátů. Pokud platnost certifikátů vyprší na uzlu řídicí roviny, může se stát, že ostatní uzly nakonec přestane být nedostupné. Pokud do tohoto stavu vstoupí všechny uzly řídicí roviny, stane se cluster nefunkčností kvůli selhání protokolu TLS. To, jestli cluster do tohoto stavu přešel, můžete ověřit tak, že se k tomuto clusteru pokoušíte získat přístup pomocí a pak ověříte, že připojení selhalo, pokud se zobrazí chybová zpráva týkající se prošlého certifikátu kubectl x509.

Tady je příklad zobrazení protokolů pro pod s předponou certificate-renewal-controller:

kubectl.exe --kubeconfig .\testcluster-kubeconfig -n=kube-system get pods 
NAME                                           READY   STATUS             RESTARTS   AGE 
… 
certificate-renewal-controller-2cdmz               1/1     Running            0          6d 

Získání protokolů z podu pro prodloužení platnosti certifikátu:

kubectl.exe --kubeconfig .\testcluster-kubeconfig -n=kube-system logs certificate-renewal-controller-2cdmz

Uzly řídicí roviny není možné znovu vytvořit jako pracovní uzly, ale k opravě chyb souvisejících s prošlou platností můžete použít modul Repair-AksHciClusterCerts. Pokud cluster začne selhávají kvůli prošlým certifikátům, spusťte příkaz , jak je uvedeno níže:

Repair-AksHciClusterCerts -Name mytargetcluster 

Pokud se cluster přes stane kubectl nedostupným, najdete protokoly ve /var/log/pods složce .

Další kroky

V tomto návodu jste se dozvěděli, jak zřídit a spravovat certifikáty. Dále můžete: