Panoramica della sicurezza della rete delle applicazioni di Azure Kubernetes (anteprima)

Importante

Le funzionalità di anteprima di AKS sono disponibili su base self-service, su scelta. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime del servizio Azure Kubernetes sono parzialmente coperte dal supporto clienti con la massima diligenza possibile. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

La rete applicativa di Azure Kubernetes protegge le comunicazioni tra i servizi nei cluster del servizio Azure Kubernetes connessi tramite l'autorizzazione automatica tls reciproca (mTLS) e basata sull'identità. Rilascia le identità di lavoro e gestisce l'emissione, la rotazione e la convalida dei certificati per abilitare comunicazioni autenticate, espressamente autorizzate e crittografate senza configurazione manuale, con crittografia conforme a FIPS durante il transito.

Questo articolo offre una panoramica delle funzionalità di sicurezza nella rete di applicazioni di Azure Kubernetes, tra cui mTLS, identità del carico di lavoro, gestione dei certificati e criteri di autorizzazione. Vengono inoltre descritte le limitazioni e i passaggi successivi per implementare la comunicazione sicura nell'ambiente di rete delle applicazioni di Azure Kubernetes.

Limitazioni

I certificati sono attualmente rilasciati da un'autorità di certificazione gestita dalla rete di applicazioni di Azure Kubernetes e non vengono concatenati a una CA pubblica.

mTLS

La rete delle applicazioni usa mTLS per fornire comunicazioni crittografate basate su identità tra carichi di lavoro. Ogni servizio in un cluster connesso alla rete di applicazioni riceve automaticamente un certificato che consente di dimostrare la propria identità e stabilire connessioni crittografate attendibili con altri servizi nella stessa rete dell'applicazione. La crittografia durante la trasmissione utilizza crittografia conforme agli standard FIPS.

Strategia di migrazione mTLS

La rete delle applicazioni consente attualmente il traffico crittografato e non crittografato. Questo approccio garantisce che i carichi di lavoro esistenti continuino a funzionare normalmente mentre i carichi di lavoro nuovi o aggiornati usano automaticamente mTLS per la comunicazione sicura. Ciò significa che è possibile adottare mTLS per la comunicazione sicura tra i carichi di lavoro senza tempi di inattività. Al termine della migrazione, è possibile passare alla modalità strict in modo che venga applicata l'autenticazione.

Vantaggi di mTLS nella rete dell'applicazione Azure Kubernetes

MTLS nella rete dell'applicazione Azure Kubernetes consente di:

Proteggere i dati in transito: tutto il traffico da servizio a servizio può essere crittografato automaticamente (conforme a FIPS).
Verificare l'identità del servizio: ogni carico di lavoro ha un certificato radice e intermedio univoco gestito dalla rete dell'applicazione.
Semplificare le operazioni: La rete dell'applicazione gestisce il rilascio, la rotazione e la revoca dei certificati per gli utenti.

Gestione dei certificati

Azure Kubernetes Application Network offre la gestione dei certificati supportata da Azure Key Vault che rilascia e gestisce i certificati usati per mTLS. Questo servizio stabilisce un limite di attendibilità condiviso tra tutti i cluster del servizio Azure Kubernetes connessi alla stessa risorsa di rete dell'applicazione.

Application Network gestisce automaticamente l'intero ciclo di vita del certificato per i certificati radice e intermedi, tra cui provisioning, rinnovo e rotazione. Ciò garantisce che le identità del carico di lavoro rimangano valide e le comunicazioni rimangano sicure nel tempo. Non è necessario creare, archiviare o ruotare manualmente i certificati.

Il diagramma seguente illustra la gerarchia dei certificati nella Rete delle applicazioni, mostrando come sono strutturati la CA radice, le CA intermedie e i certificati di carico di lavoro per stabilire fiducia tra i cluster connessi.

Gerarchia e ciclo di vita dei certificati

Quando viene creata una risorsa di Application Network, si effettua il provisioning di una CA radice per fungere da trust anchor per l'Application Network. Quando un cluster del servizio Azure Kubernetes viene aggiunto alla rete dell'applicazione come membro, Application Network rilascia un certificato intermedio per quel membro firmato dalla CA radice della rete dell'applicazione. Ogni cluster AKS connesso utilizza il certificato intermedio gestito dalla Application Network per emettere certificati di breve durata per i workload all'interno di quel cluster.

Tutti i certificati di carico di lavoro ereditano l'attendibilità dalla CA radice della rete dell'applicazione, mantenendo un confine di fiducia unificato all'interno della risorsa. La rotazione dei certificati radice e intermedi viene gestita in modo trasparente per gli utenti senza causare tempi di inattività o interruzioni del traffico. Questa gerarchia gestita garantisce un trust coerente e verificabile in tutti i cluster in una rete di applicazioni mantenendo automaticamente la validità di ogni certificato.

Da qualsiasi cluster membro è possibile ottenere il certificato CA radice dalla mappa di configurazione istio-root-cert nello spazio dei nomi applink-system.

Tipi di certificato e periodi di rotazione

Tipo di certificato	Scope	Periodo di validità	Periodo di rotazione	Purpose
CA radice	Rete dell'applicazione Azure Kubernetes	12 mesi	6 mesi	Stabilisce il limite di attendibilità per tutti i cluster connessi alla rete di applicazioni di Azure Kubernetes
CA intermedia	Cluster	90 giorni	45 giorni	Rilascia i certificati del carico di lavoro per i carichi di lavoro all'interno del cluster
Certificato del carico di lavoro	Carico di lavoro	24 ore	12 ore	Autentica i carichi di lavoro e protegge la comunicazione da servizio a servizio

Identità e autorizzazione del carico di lavoro

Man mano che le applicazioni aumentano, i servizi spesso devono comunicare in modo sicuro tra spazi dei nomi e ambienti diversi all'interno della stessa distribuzione. La gestione dei certificati e la verifica che ogni servizio possa verificare chi sta parlando può diventare rapidamente complesso e soggetto a errori. La rete dell'applicazione Azure Kubernetes elimina questo sovraccarico assegnando e gestendo automaticamente le identità del carico di lavoro.

All'interno di un ambiente connesso alla Application Network, i workload comunicano in modo sicuro all'interno e tra gli spazi dei nomi. Per garantire che ogni servizio possa essere attendibile e autenticato, La rete applicazioni assegna a ogni carico di lavoro un'identità verificabile che rappresenta lo spazio dei nomi e l'account del servizio.

Ogni carico di lavoro della Rete delle Applicazioni riceve automaticamente un'identità univoca nel formato SPIFFE, che include lo spazio dei nomi e l'account del servizio. L'identità viene formattata come segue:

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

Questa identità è incorporata nel certificato del carico di lavoro e viene usata per dimostrare l'identità del servizio durante la comunicazione con altri carichi di lavoro. La rete dell'applicazione Azure Kubernetes usa questo modello di identità basato su SPIFFE con i criteri di autorizzazione Istio, in modo da poter definire regole chiare e coerenti per cui i servizi possono comunicare.

Definire i criteri di accesso

È possibile usare Istio AuthorizationPolicies per controllare quali carichi di lavoro sono autorizzati a comunicare all'interno dell'ambiente. Questi criteri consentono di definire l'accesso in base alle identità del carico di lavoro verificate anziché ai percorsi di rete o agli indirizzi IP. Questo approccio consente di applicare controlli di accesso coerenti anche quando i servizi vengono ridimensionati e spostati tra nodi. Ad esempio, è possibile consentire solo gateway o workload specifici da spazi dei nomi attendibili di chiamare un servizio facendo riferimento alle identità SPIFFE nell'elenco dei principali dei criteri, come illustrato nell'esempio seguente.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

Linee guida per la progettazione dei criteri

Quando si progettano criteri di autorizzazione, tenere presenti le procedure consigliate seguenti:

Specificare sempre sia lo spazio dei nomi che l'account del servizio per impedire l'accesso non intenzionale tra spazi dei nomi.
Usare principali per definire identità esplicite del carico di lavoro per l'accesso con granularità fine.
Usare namespace per definire limiti di fiducia più ampi, quando appropriato.
Evitare regole che corrispondono solo ai nomi degli account di servizio senza namespace, in quanto ciò potrebbe concedere l'accesso tra cluster o ambienti.
Combinare AuthorizationPolicies con Kubernetes NetworkPolicies per applicare l'isolamento basato sulle identità e basato sulla rete.

Annotazioni

L'autorizzazione della rete dell'applicazione Azure Kubernetes si basa sull'identità del carico di lavoro verificata anziché sull'indirizzo IP. In questo modo si garantisce un'imposizione coerente anche quando i carichi di lavoro vengono ridimensionati o spostati tra i nodi.

Combinando le identità gestite da Azure Kubernetes Application Network, i certificati e i controlli delle policy, è possibile implementare una comunicazione del servizio basata su identità a privilegi minimi, garantendo un traffico autenticato, crittografato e specificamente autorizzato tra i carichi di lavoro presenti nei cluster.

Per altre informazioni sulla rete applicativa di Azure Kubernetes, vedere gli articoli seguenti:

Commenti e suggerimenti

Questa pagina è stata utile?

Ultimo aggiornamento: 2026-03-25