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

  • Articolo

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 autenticazione basata su certificati e token per proteggere le comunicazioni 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 di macchine virtuali, eliminazione e così via.
  • Pod del sistema di gestione delle chiavi (KMS): 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 reti virtuali (VNET) nel cluster.

Per comunicare con l'agente cloud, i client richiedono il provisioning dei certificati per proteggere questa comunicazione. Ogni client richiede l'associazione di un'identità, che definisce le regole RBAC (Role Based Controllo di accesso) associate al client. Ogni identità è costituita da due entità:

  • Token utilizzato per l'autenticazione iniziale, che restituisce un certificato e
  • 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 del quale scade. Per l'accesso continuo all'agente cloud, ogni client richiede il rinnovo del certificato e il token ruotato.

Tipi di certificato

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

  • Certificato CA dell'agente cloud: il certificato usato per firmare/convalidare i certificati client. Questo certificato è valido per 365 giorni (1 anno).
  • Certificati client: certificati rilasciati dal certificato CA dell'agente cloud per i client per 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 mantenuti aggiornati, ma anche per assicurarsi di accedere a nuove funzionalità, correzioni di bug e 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 nei 90 giorni predefiniti dalla data di aggiornamento del cluster.

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

I certificati vengono usati per creare comunicazioni sicure tra componenti del cluster. Il servizio Azure Kubernetes offre il provisioning senza tocco, out-of-the-box 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 i certificati e le autorità di certificazione 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 oggetto crea anche una richiesta di firma del certificato (CSR), firmata dalla CA cluster, per la comunicazione dal kubelet server API.
  • L'archivio valori chiave etcd ha un certificato firmato dalla CA cluster per la comunicazione da etcd al server API.

CA etcd

L'archivio valori 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 dei certificati

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

  • 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 revoche può essere costituito da una o più voci di revoca.

Per eseguire una revoca, usare uno dei seguenti elementi:

  • Numero di serie
  • Raggruppare
  • Nome DNS
  • Indirizzo IP

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

Nota

La revoca dei kubelet certificati server non è attualmente disponibile.

Se si usa un numero di serie quando si esegue una revoca, è possibile usare il comando di PowerShell, descritto di seguito, per ottenere il Repair-AksHciClusterCerts 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

Passaggi successivi