Overzicht van certificaatbeheer in AKS ingeschakeld door Azure Arc

Artikel
11/23/2024

Van toepassing op: AKS op Azure Stack HCI 22H2, AKS op Windows Server

AKS die is ingeschakeld door Azure Arc maakt gebruik van een combinatie van verificatie op basis van certificaten en tokens om de communicatie tussen services (of agents) die verantwoordelijk zijn voor verschillende bewerkingen binnen het platform te beveiligen. Verificatie op basis van certificaten maakt gebruik van een digitaal certificaat om een entiteit (agent, machine, gebruiker of apparaat) te identificeren voordat toegang wordt verleend tot een resource.

Cloudagent

Wanneer u AKS implementeert die is ingeschakeld door Arc, installeert AKS agents die worden gebruikt om verschillende functies in het cluster uit te voeren. Deze agents zijn onder andere:

Cloudagent: een service die verantwoordelijk is voor de onderliggende platformindeling.
Knooppuntagent: een service die zich op elk knooppunt bevindt dat het werkelijke werk doet van het maken, verwijderen van virtuele machines, enzovoort.
KMS-pod (Key Management System): een service die verantwoordelijk is voor sleutelbeheer.
Andere services: cloudoperator, certificaatbeheerder, enzovoort.

De cloudagentservice in AKS is verantwoordelijk voor het organiseren van cruD-bewerkingen (create, read, update en delete) van infrastructuuronderdelen zoals virtuele machines (VM's), virtuele netwerkinterfaces (VNIC's) en virtuele netwerken (VNET's) in het cluster.

Voor communicatie met de cloudagent moeten certificaten worden ingericht om deze communicatie te beveiligen. Voor elke client moet een identiteit worden gekoppeld, die de RBAC-regels (Role Based Access Control) definieert die aan de client zijn gekoppeld. Elke identiteit bestaat uit twee entiteiten:

Een token dat wordt gebruikt voor de eerste verificatie, die een certificaat retourneert en
Een certificaat dat is verkregen via het bovenstaande aanmeldingsproces en wordt gebruikt voor verificatie in communicatie.

Elke entiteit is geldig voor een specifieke periode (de standaardwaarde is 90 dagen), aan het einde waarvan deze verloopt. Voor continue toegang tot de cloudagent moet voor elke client het certificaat worden vernieuwd en het token gedraaid.

Certificaattypen

Er zijn twee typen certificaten die worden gebruikt in AKS die zijn ingeschakeld door Arc:

CA-certificaat voor cloudagent: het certificaat dat wordt gebruikt voor het ondertekenen/valideren van clientcertificaten. Dit certificaat is 365 dagen (1 jaar) geldig.
Clientcertificaten: certificaten die zijn uitgegeven door het CA-certificaat van de cloudagent voor clients voor verificatie bij de cloudagent. Deze certificaten zijn meestal 90 dagen geldig.

Microsoft raadt u aan clusters binnen 60 dagen na een nieuwe release bij te werken, niet alleen om ervoor te zorgen dat interne certificaten en tokens up-to-date blijven, maar ook om ervoor te zorgen dat u toegang krijgt tot nieuwe functies, bugfixes en om up-to-date te blijven met kritieke beveiligingspatches. Tijdens deze maandelijkse updates draait het updateproces alle tokens die niet automatisch kunnen worden geroteerd tijdens normale bewerkingen van het cluster. De geldigheid van certificaten en tokens wordt opnieuw ingesteld op de standaardwaarde van 90 dagen vanaf de datum waarop het cluster wordt bijgewerkt.

Communicatie beveiligen met certificaten in AKS ingeschakeld door Arc

Certificaten worden gebruikt voor het bouwen van beveiligde communicatie tussen onderdelen in het cluster. AKS biedt zero-touch, out-of-the-box inrichting en beheer van certificaten voor ingebouwde Kubernetes-onderdelen. In dit artikel leert u hoe u certificaten inricht en beheert in AKS waarvoor Arc is ingeschakeld.

Certificaten en CA's

AKS genereert en gebruikt de volgende certificeringsinstanties (CA's) en certificaten.

Cluster-CA

De API-server heeft een cluster-CA, die certificaten ondertekent voor communicatie in één richting van de API-server naar kubelet.
Elke kubelet aanvraag voor certificaatondertekening (CSR) wordt ook gemaakt, die is ondertekend door de cluster-CA, voor communicatie van de kubelet naar de API-server.
Het sleutelarchief van etcd heeft een certificaat dat is ondertekend door de cluster-CA voor communicatie van etcd naar de API-server.

etcd CA

Het sleutelarchief etcd heeft een etcd-CA die certificaten ondertekent voor verificatie en autorisatie van gegevensreplicatie tussen etcd-replica's in het cluster.

Front Proxy-CA

De Front Proxy-CA beveiligt de communicatie tussen de API-server en de API-extensieserver.

Certificaatinrichting

Certificaatinrichting voor een kubelet wordt uitgevoerd met behulp van TLS bootstrapping. Gebruik voor alle andere certificaten de op YAML gebaseerde sleutel en het maken van certificaten.

De certificaten worden opgeslagen in /etc/kubernetes/pki.
De sleutels zijn RSA 4096, EcdsaCurve: P384

Notitie

De basiscertificaten zijn 10 jaar geldig. Alle andere, niet-basiscertificaten zijn kortlevend en geldig gedurende vier dagen.

Certificaatvernieuwing en -beheer

Niet-basiscertificaten worden automatisch vernieuwd. Alle besturingsvlakcertificaten voor Kubernetes, met uitzondering van de volgende certificaten, worden beheerd:

Kubelet-servercertificaat
Kubeconfig-clientcertificaat

Als best practice voor beveiliging moet u eenmalige aanmelding van Active Directory gebruiken voor gebruikersverificatie.

Certificaatintrekking

Certificaatintrekking moet zeldzaam zijn en moet worden uitgevoerd op het moment van certificaatvernieuwing.

Zodra u het serienummer van het certificaat hebt dat u wilt intrekken, gebruikt u de aangepaste Resource van Kubernetes voor het definiëren en behouden van intrekkingsgegevens. Elk intrekkingsobject kan bestaan uit een of meer intrekkingsvermeldingen.

Gebruik een van de volgende opties om een intrekking uit te voeren:

Serienummer
Groep
DNS-naam
IP-adres

Een notBefore tijd kan worden opgegeven om alleen certificaten in te trekken die vóór een bepaalde tijdstempel worden uitgegeven. Als er notBefore geen tijd is opgegeven, worden alle bestaande en toekomstige certificaten die overeenkomen met de intrekking ingetrokken.

Notitie

Het intrekken van kubelet servercertificaten is momenteel niet beschikbaar.

Als u een serienummer gebruikt wanneer u een intrekking uitvoert, kunt u de Repair-AksHciClusterCerts PowerShell-opdracht gebruiken, zoals hieronder wordt beschreven, om uw cluster in een werkende status te krijgen. Als u een van de andere velden gebruikt die eerder worden vermeld, moet u een notBefore tijd opgeven.

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

Delen via