Procedure consigliate per la sicurezza dei pod nel servizio Azure Kubernetes
La sicurezza dei pod è un fattore fondamentale da tenere in considerazione nello sviluppo e l'esecuzione di applicazioni nel servizio Azure Kubernetes. Le applicazioni dovrebbero essere progettate in modo da concedere il numero minimo di privilegi necessari. La protezione dei dati privati è la principale preoccupazione dei clienti. Nessuno vuole che credenziali come stringhe di connessione di database, chiavi, segreti o certificati vengano esposte al mondo esterno, dove un utente malintenzionato potrebbe sfruttarle per scopi dannosi. Evitare quindi di aggiungere questi tipi di dati al codice o di incorporarli nelle immagini del contenitore. In caso contrario si creerebbe un rischio di esposizione e si limiterebbe la possibilità di ruotare queste credenziali quando sarà necessario ricompilare le immagini del contenitore.
Questo articolo di procedure consigliate è incentrato sulla protezione dei pod nel servizio Azure Kubernetes. Scopri come:
- Usare il contesto di protezione dei pod per limitare l'accesso a processi e servizi o l'escalation dei privilegi
- Eseguire l'autenticazione con altre risorse di Azure usando ID dei carichi di lavoro di Microsoft Entra
- Richiedere e recuperare credenziali da un insieme di credenziali digitali come Azure Key Vault
È anche possibile leggere le procedure consigliate per la sicurezza dei cluster e la gestione delle immagini del contenitore.
Proteggere l'accesso dei pod alle risorse
Indicazioni sulle procedure consigliate - Per eseguire l'accesso con un account utente o di gruppo diverso e limitare l'accesso ai processi e servizi dei nodi sottostanti, definire le impostazioni del contesto di protezione dei pod. Assegnare il numero minimo di privilegi necessari.
Per la corretta esecuzione delle applicazioni, i pod dovrebbero essere eseguiti come utente o gruppo definito e non come radice. Il securityContext di un pod o un contenitore consente di definire impostazioni come runAsUser o fsGroup per assumere le autorizzazioni appropriate. Assegnare solo le autorizzazioni utente o di gruppo necessarie e non usare il contesto di protezione come mezzo per assumere autorizzazioni aggiuntive. runAsUser, l'escalation dei privilegi e altre impostazioni delle funzionalità Linux sono disponibili solo nei nodi e nei pod Linux.
In un contesto di esecuzione come utente non ROOT, i contenitori non possono eseguire il binding a porte con privilegi inferiori a 1024. In questo scenario è possibile usare i servizi Kubernetes per mascherare il fatto che un'app venga eseguita su una determinata porta.
Un contesto di protezione dei pod può anche definire ulteriori funzionalità o autorizzazioni per l'accesso a processi e servizi. È possibile impostare le seguenti definizioni comuni di contesto di protezione:
- allowPrivilegeEscalation definisce se il pod può assumere privilegi radice. Progettare le applicazioni in modo che questa impostazione sia sempre false.
- Le funzionalità Linux consentono al pod di accedere ai processi dei nodi sottostanti. Prestare attenzione nell'assegnazione di queste funzionalità. Assegnare il numero minimo di privilegi necessari. Per altre informazioni, vedere Funzionalità Linux.
- Le etichette SELinux sono un modulo di sicurezza del kernel di Linux che consente di definire i criteri di accesso a servizi e processi e l'accesso al file system. Anche in questo caso, assegnare il numero minimo di privilegi necessari. Per altre informazioni, vedere Opzioni SELinux in Kubernetes
Il seguente manifesto YAML di pod di esempio imposta le impostazioni del contesto di protezione da definire:
- Il pod viene eseguito come ID utente 1000 e parte dell'ID di gruppo 2000
- Non è possibile eseguire l'escalation dei privilegi per usare
root - Le funzionalità di Linux possono accedere alle interfacce di rete e all'orologio in tempo reale (hardware) dell'host
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
fsGroup: 2000
containers:
- name: security-context-demo
image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
securityContext:
runAsUser: 1000
allowPrivilegeEscalation: false
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
Consultare l'operatore del cluster per determinare le impostazioni del contesto di protezione necessarie. Cercare di progettare le applicazioni in modo da ridurre al minimo le autorizzazioni aggiuntive e l'accesso necessari al pod. Sono disponibili altre funzionalità di sicurezza per limitare l'accesso mediante AppArmor e seccomp (elaborazione sicura), che possono essere implementate dagli operatori cluster. Per altre informazioni, vedere Proteggere l'accesso del contenitore alle risorse.
Limitare l'esposizione delle credenziali
Indicazioni sulle procedure consigliate - Non definire credenziali nel codice dell'applicazione. Usare le identità gestite per le risorse di Azure per consentire al pod di richiedere l'accesso ad altre risorse. Occorre anche usare un insieme di credenziali digitali, come Azure Key Vault, per archiviare e recuperare le chiavi e le credenziali digitali. Le identità gestite da pod sono destinate all'uso solo con pod Linux e immagini del contenitore.
Per limitare il rischio di esposizione delle credenziali nel codice dell'applicazione, evitare l'uso di credenziali predefinite o condivise. Le credenziali o le chiavi non devono essere incluse direttamente nel codice. In caso di esposizione delle credenziali, è necessario aggiornare o ridistribuire l'applicazione. Un approccio migliore consiste nell'assegnare ai pod la propria identità e un modo per autenticare se stessi oppure nel recuperare automaticamente le credenziali da un insieme di credenziali digitali.
Usare un ID dei carichi di lavoro di Microsoft Entra
Un'identità del carico di lavoro è un'identità usata da un'applicazione in esecuzione in un pod che può autenticarsi con altri servizi di Azure che la supportano, ad esempio Archiviazione o SQL. Si integra con le funzionalità native di Kubernetes per la federazione con provider di identità esterni. In questo modello di sicurezza, il cluster del servizio Azure Kubernetes funge da emittente del token, Microsoft Entra ID usa OpenID Connessione per individuare le chiavi di firma pubbliche e verificare l'autenticità del token dell'account del servizio prima di scambiarlo per un token Microsoft Entra. Il carico di lavoro può scambiare un token dell'account del servizio proiettato nel volume per un token Microsoft Entra usando la libreria client di Identità di Azure usando Azure SDK o Microsoft Authentication Library (MSAL).
Per altre informazioni sulle identità del carico di lavoro, vedere Configurare un cluster del servizio Azure Kubernetes per l'uso di ID dei carichi di lavoro di Microsoft Entra con le applicazioni
Usare Azure Key Vault con il driver CSI dell'archivio di segreti
L'uso del ID dei carichi di lavoro di Microsoft Entra abilita l'autenticazione per il supporto dei servizi di Azure. Per i propri servizi o applicazioni senza identità gestite per le risorse di Azure l'autenticazione viene ancora eseguita con credenziali o chiavi. Per archiviare il contenuto dei segreti è possibile usare un insieme di credenziali digitali.
Quando le applicazioni hanno bisogno di credenziali, comunicano con l'insieme di credenziali digitali, recuperano i contenuti di segreti più recenti e quindi si connettono al servizio necessario. Questo insieme di credenziali digitali può essere Azure Key Vault. Il flusso di lavoro semplificato per il recupero di credenziali da Azure Key Vault mediante le identità gestite del pod è illustrato nel diagramma seguente:
Con Azure Key Vault segreti come credenziali, chiavi dell'account di archiviazione o certificati vengono archiviati e sottoposti a regolare rotazione. È possibile integrare Azure Key Vault con un cluster del servizio Azure Kubernetes usando il provider di Azure Key Vault per il driver CSI dell'archivio di segreti. Il driver CSI dell'archivio di segreti consente al cluster del servizio Azure Kubernetes di recuperare i contenuti di segreti in modo nativo da Key Vault e fornirle in tutta sicurezza solo al pod che le ha richieste. Collaborare con l'operatore del cluster per distribuire il driver CSI dell'archivio di segreti nei nodi di lavoro del servizio Azure Kubernetes. È possibile usare un ID dei carichi di lavoro di Microsoft Entra per richiedere l'accesso a Key Vault e recuperare il contenuto del segreto necessario tramite il driver CSI dell'archivio segreti.
Passaggi successivi
In questo articolo è stato illustrato in particolare come proteggere i pod. Per implementare alcune di queste aree, vedere gli articoli seguenti: