Säker kommunikation med certifikat
Certifikat används för att skapa säker kommunikation mellan komponenter i klustret. Azure Kubernetes Service (AKS) på Azure Stack HCI och Windows Server tillhandahåller zero-touch, out-of-the-box-etablering och hantering av certifikat för inbyggda Kubernetes-komponenter.
Certifikat och certifikatutfärdare
AKS på Azure Stack HCI och Windows Server genererar och använder följande certifikat och certifikatutfärdare :
Kluster-CA:
- API-servern har en kluster-CA som signerar certifikat för enkelriktad kommunikation från API-servern till
kubelet. - Var och
kubeleten skapar också en begäran om certifikatsignering (CSR), som signeras av klustercertifikatutfärdaren, för kommunikation från kubelet till API-servern. - Nyckelvärdearkivet etcd har ett certifikat signerat av klustercertifikatutfärdare för kommunikation från etcd till API-servern.
etcd CA:
- Nyckelvärdelagret etcd har en certifikatutfärdare med etcd som signerar certifikat för att autentisera och auktorisera datareplikering mellan etcd-repliker i klustret.
Klientproxy-CA
- Klientproxy-CA:n skyddar kommunikationen mellan API-servern och tilläggs-API-servern.
Certifikatetablering
Certifikatetablering för kubelets görs med TLS-bootstrapping. För alla andra certifikat använder du YAML-baserad nyckel och skapande av certifikat.
- Certifikaten lagras på /etc/kubernetes/pki
- Nycklarna är RSA 4096, EcdsaCurve: P384
Anteckning
Rotcertifikaten är giltiga i 10 år. Alla andra icke-rotcertifikat är kortlivade och giltiga i fyra dagar.
Förnyelse och hantering av certifikat
Icke-rotcertifikat förnyas automatiskt. Alla kontrollplanscertifikat för Kubernetes hanteras förutom följande certifikat:
- Kubelet-servercertifikat
- Kubeconfig-klientcertifikat
Vi rekommenderar att du använder enkel inloggning i Active Directory för användarautentisering.
Återkallning av certifikat
Återkallande bör vara en sällsynt incident och tillämpas vid tidpunkten för certifikatförnyelse.
När du har serienumret för certifikatet som du vill återkalla använder du Kubernetes Anpassad resurs för att definiera och bevara återkallningsinformation. Varje återkallningsobjekt kan bestå av en eller flera återkallningsförsök.
Om du vill utföra ett återkallningsfel använder du något av följande:
- Serienummer
- Group
- DNS-namn
- IP-adress
En notBefore-tid kan anges för att endast återkalla certifikat som utfärdas före en viss tidsstämpel. Om en notBefore-tid inte har angetts återkallas alla befintliga och framtida certifikat som matchar återkallningen.
Anteckning
Återkallning för servercertifikat är inte tillgängligt för kubelet närvarande.
Så länge återkallningen utfördes med ett serienummer kan du använda Repair-AksHciClusterCerts PowerShell-kommandot som beskrivs nedan för att få klustret i ett fungerande tillstånd. Om återkallningen utfördes med hjälp av andra fält måste du ange notBefore time så att du kan återställa klustret med kommandot Repair-AksHciClusterCerts .
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
Felsöka och underhålla
Se följande skript och dokumentation för loggning och övervakning:
Förnya certifikat för arbetsnoder
För arbetsnoder loggas misslyckade certifikatförnyelser av podden certificate-renewal-worker . Om certifikatförnyelsen fortsätter att misslyckas på en arbetsnod och certifikaten upphör att gälla tas noden bort och en ny arbetsnod skapas i stället.
Här är ett exempel på hur du visar loggarna för podden med prefixet 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
Så här hämtar du loggarna från certifikatförnyelsepodden:
kubectl.exe --kubeconfig .\testcluster-kubeconfig -n=kube-system logs certificate-renewal-worker-6f68k
Förnya certifikat för kontrollplansnoder
För kontrollplansnoder loggas misslyckade certifikatförnyelser av podden certificate-renewal-controller. Om certifikat upphör att gälla på en kontrollplansnod kan det så småningom bli oåtkomligt för andra noder. Om alla kontrollplansnoder anger det här tillståndet blir klustret obrukbart på grund av ett TLS-fel. Du kan bekräfta om klustret har angett det här tillståndet genom att försöka komma åt det med hjälp av kubectloch sedan kontrollera att anslutningen misslyckades om det finns ett felmeddelande om utgångna x509-certifikat.
Här är ett exempel på hur du visar loggarna för podden med prefixet 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
Så här hämtar du loggarna från certifikatförnyelsepodden:
kubectl.exe --kubeconfig .\testcluster-kubeconfig -n=kube-system logs certificate-renewal-controller-2cdmz
Kontrollplansnoder kan inte återskapas som arbetsnoder, men du kan använda modulen Repair-AksHciClusterCerts för att åtgärda fel som rör utgångna certifikat. Om klustret börjar misslyckas på grund av utgångna certifikat kör du kommandot enligt nedan:
Repair-AksHciClusterCerts -Name mytargetcluster
Om klustret inte kan nås via kubectlhittar du loggarna /var/log/pods i mappen .
Nästa steg
I den här guiden har du lärt dig hur du etablerar och hanterar certifikat. Sedan kan du: