Översikt över certifikathantering i AKS som aktiveras av Azure Arc

  • Artikel

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

AKS som aktiveras av Azure Arc 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 du beviljar åtkomst till en resurs.

Molnagent

När du distribuerar AKS aktiverat av Arc 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 det faktiska arbetet med att skapa, ta bort virtuella datorer osv.
  • Key Management System-podd (KMS): en tjänst som ansvarar för nyckelhantering.
  • Andra tjänster: molnoperatör, certifikathanterare osv.

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

För att kunna kommunicera med molnagenten kräver klienterna 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), i slutet av vilken den upphör att gälla. För fortsatt åtkomst till molnagenten kräver varje klient att certifikatet förnyas och token roteras.

Certifikattyper

Det finns två typer av certifikat som används i AKS som är aktiverade av Arc:

  • 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 molnagentens CA-certifikat för klienter som ska autentiseras mot 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 normala åtgärder i klustret. Certifikat- och token-giltigheten återställs till standardvärdet 90 dagar från det datum då klustret uppdateras.

Säker kommunikation med certifikat i AKS som aktiveras av Arc

Certifikat används för att skapa säker kommunikation mellan komponenter i klustret. AKS 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 som aktiveras av Arc.

Certifikat och certifikatutfärdare

AKS 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 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 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 kortlivade och giltiga i fyra dagar.

Förnyelse och hantering av certifikat

Icke-rotcertifikat förnyas automatiskt. Alla kontrollplanscertifikat för Kubernetes förutom 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 sällsynt och bör göras 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 ingen notBefore tid anges återkallas alla befintliga och framtida certifikat som matchar återkallningen.

Anteckning

Det är för närvarande inte tillgängligt att återkalla kubelet servercertifikat.

Om du använder ett serienummer när du utför ett återkallningstillstånd 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