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

Artikel
11/23/2024

Gäller för: AKS på Azure Local 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 åtkomst beviljas 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 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 ansvarar för att orkestrera crud-åtgärderna (create, read, update och delete) för infrastrukturkomponenter som virtuella datorer (VM), virtuella nätverksgränssnitt (VNICs) 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, vilket definierar de RBAC-regler (Rollbaserad åtkomstkontroll) 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ämtas från inloggningsprocessen ovan och 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 aktiveras 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 ca-certifikatet för molnagenten för klienter som ska autentiseras 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, buggkorrigeringar och för att hålla dig uppdaterad med kritiska 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 aktiverat 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 certifikatsigneringsbegäran (CSR), som är signerad av klustercertifikatutfärdaren, för kommunikation från kubelet till API-servern.
Värdearkivet etcd-nyckel har ett certifikat signerat av klustercertifikatutfärdare för kommunikation från etcd till API-servern.

etcd CA

Värdearkivet etcd key har en etsad certifikatutfärdare som signerar certifikat för att autentisera och auktorisera datareplikering mellan repliker etcd 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-bootstrapping. 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

Kommentar

Rotcertifikaten är giltiga i 10 år. Alla andra certifikat som inte är rotcertifikat är kortvariga 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 säkerhet bör du använda enkel inloggning med Active Directory för användarautentisering.

Återkallande 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 det certifikat som du vill återkalla använder du Kubernetes anpassade 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
Grupp
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 anges återkallas alla befintliga och framtida certifikat som matchar återkallningen.

Kommentar

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 återkallande 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

Dela via