Översikt över certifikathantering

  • Artikel

Gäller för: AKS på Azure Stack HCI, AKS på Windows Server

AKS-hybrid använder en kombination av certifikat- och tokenbaserad autentisering för att skydda kommunikationen mellan tjänster (eller agenter) som ansvarar för olika åtgärder inom plattformen. Certifikatbaserad autentisering använder ett digitalt certifikat för att identifiera en entitet (agent, dator, användare eller enhet) innan åtkomst beviljas till en resurs. AKS-hybrid stöder hybriddistributionsalternativ för Azure Kubernetes Service (AKS).

Molnagent

När du distribuerar AKS-hybrid installerar AKS agenter som används för att utföra olika funktioner i klustret. Dessa agenter omfattar:

  • Molnagent: en tjänst som ansvarar för den underliggande plattformsorkestreringen.
  • Nodagent: en tjänst som finns på varje nod som utför själva arbetet med att skapa, ta bort och ta bort virtuella datorer.
  • Key Management System-podd (KMS): en tjänst som ansvarar för nyckelhantering.
  • Andra tjänster – molnoperatör, certifikathanterare osv.

Molnagenttjänsten i AKS-hybriden ansvarar för att samordna CRUD-åtgärderna (create, read, update och delete) för infrastrukturkomponenter som Virtual Machines (VM), Virtual Network Interfaces (VNIC) och virtuella nätverk (VNET) i klustret.

För att kommunicera med molnagenten kräver klienter att certifikat etableras för att skydda den här kommunikationen. Varje klient kräver att en identitet associeras med den, som definierar de rollbaserade Access Control-reglerna (RBAC) som är associerade med klienten. Varje identitet består av två entiteter:

  • En token som används för inledande autentisering, som returnerar ett certifikat, och
  • Ett certifikat som hämtats från inloggningsprocessen ovan och som används för autentisering i all kommunikation.

Varje entitet är giltig under en viss period (standardvärdet är 90 dagar) och upphör att gälla. För fortsatt åtkomst till molnagenten kräver varje klient att certifikatet förnyas och att token roteras.

Certifikattyper

Det finns två typer av certifikat som används i AKS-hybrid:

  • Ca-certifikat för molnagent: certifikatet som används för att signera/verifiera klientcertifikat. Det här certifikatet är giltigt i 365 dagar (1 år).
  • Klientcertifikat: certifikat som utfärdats av ca-certifikatet för molnagenten så att klienter kan autentisera till molnagenten. Dessa certifikat är vanligtvis giltiga i 90 dagar.

Microsoft rekommenderar att du uppdaterar kluster inom 60 dagar efter en ny version, inte bara för att säkerställa att interna certifikat och token hålls uppdaterade, utan även för att se till att du får åtkomst till nya funktioner, felkorrigeringar och för att hålla dig uppdaterad med viktiga säkerhetskorrigeringar. Under dessa månatliga uppdateringar roterar uppdateringsprocessen alla token som inte kan roteras automatiskt under normal drift av klustret. Certifikat och tokens giltighet återställs till standardvärdet 90 dagar från det datum då klustret uppdateras.

Säker kommunikation med certifikat i AKS-hybrid

Certifikat används för att skapa säker kommunikation mellan komponenter i klustret. AKS-hybrid tillhandahåller zero-touch, out-of-the-box-etablering och hantering av certifikat för inbyggda Kubernetes-komponenter. I den här artikeln får du lära dig hur du etablerar och hanterar certifikat i AKS-hybrid.

Certifikat och certifikatutfärdare

AKS-hybrid genererar och använder följande certifikatutfärdare och certifikat.

Kluster-CA:

  • API-servern har en kluster-CA som signerar certifikat för enkelriktad kommunikation från API-servern till kubelet.
  • Var och kubelet en skapar också en certifikatsigneringsbegäran (CSR), som signeras av klustercertifikatutfärdaren, för kommunikation från kubelet till API-servern.
  • Nyckelvärdesarkivet etcd har ett certifikat signerat av kluster-CA:n för kommunikation från etcd till API-servern.

etcd CA:

  • Nyckelvärdesarkivet etcd har en certifikatutfärdare med etc. 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 API-tilläggsservern.

Certifikatetablering

Certifikatetablering för en kubelet görs med TLS-start. För alla andra certifikat använder du YAML-baserad nyckel och skapande av certifikat.

  • Certifikaten lagras i /etc/kubernetes/pki.
  • Nycklarna är RSA 4096, EcdsaCurve: P384

Anteckning

Rotcertifikaten är giltiga i 10 år. Alla andra icke-rotcertifikat är kortvariga och giltiga i fyra dagar.

Förnyelse och hantering av certifikat

Icke-rotcertifikat förnyas automatiskt. Alla kontrollplanscertifikat för Kubernetes utom följande certifikat hanteras:

  • Kubelet-servercertifikat
  • Kubeconfig-klientcertifikat

Som bästa praxis för säkerhet bör du använda enkel inloggning i Active Directory för användarautentisering.

Återkallning av certifikat

Återkallande av certifikat bör vara ovanligt och bör göras vid tidpunkten för certifikatförnyelsen.

När du har serienumret för certifikatet som du vill återkalla använder du Anpassad Kubernetes-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 ingen notBefore tid anges återkallas alla befintliga och framtida certifikat som matchar återkallningen.

Anteckning

Återkallning av kubelet servercertifikat är inte tillgängligt för närvarande.

Om du använder ett serienummer när du gör ett återkallningsanrop kan du använda Repair-AksHciClusterCerts PowerShell-kommandot, som beskrivs nedan, för att få klustret i ett fungerande tillstånd. Om du använder något av de andra fälten som angavs tidigare måste du ange en notBefore tid.

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

Nästa steg