Zabezpečená komunikace s certifikáty v hybridní službě AKS

Platí pro: AKS v Azure Stack HCI, AKS na Windows Serveru

Certifikáty se používají k vytvoření zabezpečené komunikace mezi komponentami v clusteru. Hybridní AKS poskytuje bezobslužné zřizování a správu certifikátů pro integrované komponenty Kubernetes. V tomto článku se dozvíte, jak zřizovat a spravovat certifikáty v hybridní službě AKS.

Certifikáty a certifikační autority

Hybridní AKS generuje a používá následující certifikační autority (CA) a certifikáty.

Certifikační autorita clusteru:

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

certifikační autorita etcd:

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

Front Proxy CA

• Přední proxy certifikační autorita zabezpečuje komunikaci mezi serverem rozhraní API a serverem rozhraní API rozšíření.

Zřizování certifikátů

Zřizování certifikátů pro objekt se provádí pomocí bootstrappingukubelet TLS. Pro všechny ostatní certifikáty použijte klíč založený na YAML a vytvoření certifikátu.

• Certifikáty jsou uložené v /etc/kubernetes/pki.
• Klíče jsou RSA 4096, EcdsaCurve: P384

Poznámka

Kořenové certifikáty jsou platné 10 let. Všechny ostatní certifikáty, které nejsou rootem, jsou krátkodobé a jsou platné čtyři dny.

Obnovení a správa certifikátů

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

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

Jako osvědčený postup zabezpečení byste k ověřování uživatelů měli použít jednotné přihlašování Active Directory .

Odvolání certifikátu

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

Jakmile budete mít sériové číslo certifikátu, který chcete odvolat, použijte k definování a zachová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í.

Pokud chcete provést odvolání, použijte jednu z následujících možností:

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

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

Poznámka

kubelet Odvolání certifikátů serveru v současné době není k dispozici.

Pokud při odvolání použijete sériové číslo, můžete cluster do funkčního stavu dostat do funkčního stavu pomocí Repair-AksHciClusterCerts příkazu PowerShellu popsaného níže. Pokud použijete některé z dalších polí uvedených výše, nezapomeňte zadat notBefore time, abyste mohli cluster obnovit pomocí Repair-AksHciClusterCerts 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:

• Protokolování
• Monitorování

Obnovení certifikátů pro pracovní uzly

U pracovních uzlů se neúspěšná obnovení certifikátů protokolují pomocí podu certificate-renewal-worker . Pokud obnovení certifikátu na pracovním uzlu dál selže a platnost certifikátů vyprší, uzel se odebere a místo toho 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 se neúspěšná obnovení certifikátů protokolují pomocí podu certificate-renewal-controller . Pokud platnost certifikátů na uzlu řídicí roviny vyprší, může se uzel nakonec stát nedostupným pro jiné uzly. Pokud všechny uzly řídicí roviny přejdou do tohoto stavu, cluster přestane fungovat kvůli selhání protokolu TLS. Pokud chcete ověřit, jestli cluster přešel do tohoto stavu, zkuste ke clusteru získat přístup pomocí kubectla pak ověřte, jestli připojení selže s chybovou zprávou související s prošlými certifikáty 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 se nedají znovu vytvořit jako pracovní uzly, ale k opravě chyb souvisejících s prošlými certifikáty můžete použít modul Repair-AksHciClusterCerts . Pokud cluster začne selhávat kvůli prošlým certifikátům, spusťte následující příkaz:

Repair-AksHciClusterCerts -Name mytargetcluster 

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

Další kroky

V tomto průvodci jste se naučili zřizovat a spravovat certifikáty. Dále můžete:

• Nasazení linuxových aplikací v clusteru Kubernetes
• Nasazení aplikace Windows Serveru v clusteru Kubernetes