Gestione degli accessi ai cluster

Una gestione efficace degli accessi è fondamentale per mantenere la sicurezza e l'integrità dei cluster Amazon EKS. Questa guida esplora varie opzioni per la gestione degli accessi EKS, con particolare attenzione all'utilizzo di AWS IAM Identity Center (precedentemente AWS SSO). Confronteremo diversi approcci, discuteremo i loro compromessi ed evidenzieremo le limitazioni e le considerazioni note.

Opzioni di gestione degli accessi EKS

Nota

ConfigMapla gestione degli accessi basata su tecnologia (aws-auth ConfigMap) è obsoleta e sostituita dall'API Cluster Access Management (CAM). Per i nuovi cluster EKS, implementa l'API CAM per gestire l'accesso ai cluster. Per i cluster esistenti che utilizzano aws-auth ConfigMap, esegui la migrazione all'utilizzo dell'API CAM.

Opzione 1: AWS IAM Identity Center con API Cluster Access Management (CAM)

• Gestione centralizzata di utenti e autorizzazioni

• Integrazione con provider di identità esistenti (ad esempio Microsoft AD, Okta PingId e altri)

• L'API CAM utilizza Access Entries per collegare i principali (utenti o ruoli) di AWS IAM al cluster EKS. Queste voci funzionano con le identità gestite di IAM Identity Center e consentono agli amministratori di controllare l'accesso al cluster per utenti e gruppi definiti in Identity Center.

Flusso di autenticazione del cluster EKS:

1. I principali (utenti umani) o i processi automatizzati si autenticano tramite AWS IAM presentando le autorizzazioni appropriate all'account AWS. In questa fase, vengono mappati sul principale AWS IAM appropriato (ruolo o utente).

2. Successivamente, una voce di accesso EKS mappa questo principale IAM su un principale Kubernetes RBAC (utente o gruppo) definendo una politica di accesso appropriata, che contiene solo le autorizzazioni Kubernetes.

3. Quando un utente finale Kubernetes tenta di accedere a un cluster, la sua richiesta di autenticazione viene elaborata dalla nostra CLI di aws-iam-authenticator AWS EKS e convalidata rispetto al contesto del cluster nel file kubeconfig.

4. Infine, l'autorizzatore EKS verifica le autorizzazioni associate all'accesso dell'utente autenticato e concede o nega l'accesso di conseguenza.

   • L'API utilizza policy di accesso specifiche di Amazon EKS per definire il livello di autorizzazione per ogni Access Entry. Queste policy possono essere mappate su ruoli e autorizzazioni configurati in IAM Identity Center, garantendo un controllo coerente degli accessi tra i servizi AWS e i cluster EKS.

Vantaggi rispetto alla gestione degli accessi ConfigMap basata:

1. Riduzione del rischio di errori di configurazione: la gestione diretta basata su API elimina gli errori comuni associati alla modifica manuale. ConfigMap Questo aiuta a prevenire eliminazioni accidentali o errori di sintassi che potrebbero impedire agli utenti di accedere al cluster.

2. Principio avanzato del privilegio minimo: elimina la necessità dell'autorizzazione di amministratore del cluster dall'identità del creatore del cluster e consente un'assegnazione delle autorizzazioni più granulare e appropriata. Puoi scegliere di aggiungere questa autorizzazione per i casi d'uso «break-glass».

3. Modello di sicurezza avanzato: fornisce la convalida integrata delle voci di accesso prima che vengano applicate. Inoltre, offre una più stretta integrazione con AWS IAM per l'autenticazione.

4. Operazioni semplificate: offre un modo più intuitivo per gestire le autorizzazioni tramite strumenti nativi di AWS.

Migliori pratiche:

1. Usa AWS Organizations per gestire più account e applicare policy di controllo dei servizi (SCPs).

2. Implementa il principio del privilegio minimo creando set di autorizzazioni specifici per diversi ruoli EKS (ad esempio amministratore, sviluppatore, sola lettura).

3. Utilizza il controllo degli accessi basato sugli attributi (ABAC) per assegnare dinamicamente le autorizzazioni ai pod in base agli attributi utente.

4. Controlla e rivedi regolarmente le autorizzazioni di accesso.

Considerazioni/limitazioni:

1. I ruoli ARNs generati da Identity Center hanno suffissi casuali, il che li rende difficili da usare nelle configurazioni statiche.

2. Supporto limitato per autorizzazioni granulari a livello di risorse Kubernetes. È necessaria una configurazione aggiuntiva per i ruoli RBAC personalizzati di Kubernetes. Oltre all'RBAC nativo di Kubernetes, prendi in considerazione l'utilizzo di Kyverno per la gestione avanzata delle autorizzazioni nei cluster EKS.

Opzione 2: AWS IAM Users/Roles mappato su gruppi Kubernetes

Vantaggi:

1. Controllo granulare sulle autorizzazioni IAM.

2. Ruolo prevedibile e statico ARNs

Contro:

1. Maggiore sovraccarico di gestione per gli account utente

2. Mancanza di gestione centralizzata delle identità

3. Potenziale di proliferazione delle entità IAM

Migliori pratiche:

1. Utilizza i ruoli IAM anziché gli utenti IAM per migliorare la sicurezza e la gestibilità

2. Implementa una convenzione di denominazione per i ruoli per garantire coerenza e facilità di gestione

3. Utilizza le condizioni delle policy IAM per limitare l'accesso in base a tag o altri attributi.

4. Ruota regolarmente le chiavi di accesso e rivedi le autorizzazioni.

Considerazioni/limitazioni:

1. Problemi di scalabilità nella gestione di un numero elevato di utenti o ruoli

2. Nessuna funzionalità Single Sign-On integrata

Opzione 3: fornitori OIDC

Vantaggi:

1. Integrazione con i sistemi di gestione delle identità esistenti

2. Sovraccarico di gestione ridotto per gli account utente

Contro:

1. Complessità di configurazione aggiuntiva

2. Potenziale aumento della latenza durante l'autenticazione

3. Dipendenza da un provider di identità esterno

Migliori pratiche:

1. Configura attentamente il provider OIDC per garantire la convalida sicura dei token.

2. Utilizza token di breve durata e implementa meccanismi di aggiornamento dei token.

3. Controlla e aggiorna regolarmente le configurazioni OIDC.

Consulta questa guida per un'implementazione di riferimento sull'integrazione di provider Single Sign-On esterni con Amazon EKS

Considerazioni/limitazioni:

1. Integrazione nativa limitata con i servizi AWS rispetto a IAM.

2. L'URL dell'emittente del provider OIDC deve essere accessibile al pubblico affinché EKS possa scoprire le chiavi di firma.

AWS EKS Pod Identity e IRSA per carichi di lavoro

Amazon EKS offre due modi per concedere le autorizzazioni AWS IAM ai carichi di lavoro eseguiti nei cluster Amazon EKS: ruoli IAM per account di servizio (IRSA) e EKS Pod Identities.

Sebbene sia IRSA che EKS Pod Identities offrano i vantaggi dell'accesso con privilegi minimi, dell'isolamento delle credenziali e della verificabilità, EKS Pod Identity è il metodo consigliato per concedere le autorizzazioni ai carichi di lavoro.

Per una guida dettagliata sull'identità e le credenziali per i pod EKS, consulta la sezione Identità e credenziali delle migliori pratiche di sicurezza.

Raccomandazione

Combina IAM Identity Center con l'API CAM

• Gestione semplificata: utilizzando l'API Cluster Access Management in combinazione con IAM Identity Center, gli amministratori possono gestire l'accesso al cluster EKS insieme ad altri servizi AWS, riducendo la necessità di passare da un'interfaccia all'altra o di modificare manualmente. ConfigMaps

• Utilizza le voci di accesso per gestire le autorizzazioni Kubernetes dei principali IAM dall'esterno del cluster. Puoi aggiungere e gestire l'accesso al cluster utilizzando l'API EKS, l'interfaccia a riga di comando AWS, AWS SDKs CloudFormation, AWS e la console di gestione AWS. Ciò significa che puoi gestire gli utenti con gli stessi strumenti con cui hai creato il cluster.

• Le autorizzazioni granulari di Kubernetes possono essere applicate mappando utenti o gruppi Kubernetes con principi IAM associati alle identità SSO tramite voci di accesso e policy di accesso.

• Per iniziare, segui Cambia la modalità di autenticazione per utilizzare le voci di accesso, quindi Migrazione delle voci aws-auth esistenti per accedere alle voci. ConfigMap