Panoramica della gestione dei certificati nel servizio Azure Kubernetes abilitata da Azure Arc

Articolo
11/23/2024

Si applica a: Servizio Azure Kubernetes in Azure Stack HCI 22H2, servizio Azure Kubernetes in Windows Server

Il servizio Azure Kubernetes abilitato da Azure Arc usa una combinazione di certificati e autenticazione basata su token per proteggere la comunicazione tra servizi (o agenti) responsabili di diverse operazioni all'interno della piattaforma. L'autenticazione basata su certificati usa un certificato digitale per identificare un'entità (agente, computer, utente o dispositivo) prima di concedere l'accesso a una risorsa.

Agente cloud

Quando si distribuisce il servizio Azure Kubernetes abilitato da Arc, il servizio Azure Kubernetes installa gli agenti usati per eseguire varie funzioni all'interno del cluster. Questi agenti includono:

Agente cloud: un servizio responsabile dell'orchestrazione della piattaforma sottostante.
Agente del nodo: un servizio che risiede in ogni nodo che esegue il lavoro effettivo della creazione, dell'eliminazione e così via della macchina virtuale.
Pod del Servizio di gestione delle chiavi: un servizio responsabile della gestione delle chiavi.
Altri servizi: operatore cloud, gestione certificati e così via.

Il servizio agente cloud nel servizio Azure Kubernetes è responsabile dell'orchestrazione delle operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD) dei componenti dell'infrastruttura, ad esempio Macchine virtuali (VM), interfacce Rete virtuale (VNIC) e Rete virtuale (VNET) nel cluster.

Per comunicare con l'agente cloud, i client richiedono il provisioning dei certificati per proteggere questa comunicazione. A ogni client è richiesta l'associazione di un'identità, che definisce le regole di Controllo di accesso controllo degli accessi in base al ruolo associate al client. Ogni identità è costituita da due entità:

Token, usato per l'autenticazione iniziale, che restituisce un certificato e
Un certificato, ottenuto dal processo di accesso precedente e usato per l'autenticazione in qualsiasi comunicazione.

Ogni entità è valida per un periodo specifico (il valore predefinito è 90 giorni), alla fine della quale scade. Per l'accesso continuo all'agente cloud, ogni client richiede il rinnovo del certificato e la rotazione del token.

Tipi di certificato

Esistono due tipi di certificati usati nel servizio Azure Kubernetes abilitato da Arc:

Certificato della CA dell'agente cloud: certificato usato per firmare/convalidare i certificati client. Questo certificato è valido per 365 giorni (1 anno).
Certificati client: certificati rilasciati dal certificato della CA dell'agente cloud per consentire ai client di eseguire l'autenticazione all'agente cloud. Questi certificati sono in genere validi per 90 giorni.

Microsoft consiglia di aggiornare i cluster entro 60 giorni da una nuova versione, non solo per garantire che i certificati e i token interni siano aggiornati, ma anche per assicurarsi di ottenere l'accesso a nuove funzionalità, correzioni di bug e per rimanere aggiornati con le patch di sicurezza critiche. Durante questi aggiornamenti mensili, il processo di aggiornamento ruota tutti i token che non possono essere ruotati automaticamente durante le normali operazioni del cluster. La validità del certificato e del token viene reimpostata sui 90 giorni predefiniti dalla data in cui il cluster viene aggiornato.

Proteggere la comunicazione con i certificati nel servizio Azure Kubernetes abilitato da Arc

I certificati vengono usati per creare comunicazioni sicure tra i componenti del cluster. Il servizio Azure Kubernetes offre il provisioning predefinito e la gestione dei certificati per i componenti Kubernetes predefiniti. In questo articolo si apprenderà come effettuare il provisioning e gestire i certificati nel servizio Azure Kubernetes abilitato da Arc.

Certificati e ca

Il servizio Azure Kubernetes genera e usa le autorità di certificazione e i certificati seguenti.

Cluster CA

Il server API dispone di una CA cluster che firma i certificati per la comunicazione unidirezionale dal server API a kubelet.
Ogni kubelet crea anche una richiesta di firma del certificato (CSR), firmata dalla CA del cluster, per la kubelet comunicazione dal server API al server API.
L'archivio dei valori di chiave etcd ha un certificato firmato dalla CA del cluster per la comunicazione da etcd al server API.

CA etcd

L'archivio dei valori di chiave etcd ha una CA etcd che firma i certificati per autenticare e autorizzare la replica dei dati tra repliche etcd nel cluster.

CA proxy front-end

La CA front proxy protegge la comunicazione tra il server API e il server API di estensione.

Provisioning del certificato

Il provisioning dei certificati per un kubelet oggetto viene eseguito usando il bootstrap TLS. Per tutti gli altri certificati, usare la chiave basata su YAML e la creazione di certificati.

I certificati vengono archiviati in /etc/kubernetes/pki.
Le chiavi sono RSA 4096, EcdsaCurve: P384

Nota

I certificati radice sono validi per 10 anni. Tutti gli altri certificati non radice sono di breve durata e validi per quattro giorni.

Rinnovo e gestione dei certificati

I certificati non radice vengono rinnovati automaticamente. Tutti i certificati del piano di controllo per Kubernetes, ad eccezione dei certificati seguenti sono gestiti:

Certificato del server Kubelet
Certificato client Kubeconfig

Come procedura consigliata per la sicurezza, è consigliabile usare l'accesso Single Sign-In di Active Directory per l'autenticazione utente.

Revoca del certificato

La revoca dei certificati deve essere rara e deve essere eseguita al momento del rinnovo del certificato.

Dopo aver ottenuto il numero di serie del certificato da revocare, usare la risorsa personalizzata Kubernetes per definire e rendere persistenti le informazioni di revoca. Ogni oggetto di revoca può essere costituito da una o più voci di revoca.

Per eseguire una revoca, usare una delle opzioni seguenti:

Numero di serie
Raggruppa
Nome DNS
Indirizzo IP

È possibile specificare un'ora notBefore per revocare solo i certificati rilasciati prima di un determinato timestamp. Se non viene specificata un'ora notBefore , verranno revocati tutti i certificati esistenti e futuri corrispondenti alla revoca.

Nota

La revoca dei certificati server kubelet non è attualmente disponibile.

Se si usa un numero di serie quando si esegue una revoca, è possibile usare il Repair-AksHciClusterCerts comando PowerShell, descritto di seguito, per ottenere il cluster in uno stato di lavoro. Se si usa uno degli altri campi elencati in precedenza, assicurarsi di specificare un'ora notBefore .

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

Condividi tramite