Errore "Your current user or role does not have access to Kubernetes objects" su AWS EKS

Utilizzando Amazon Elastic Kubernetes Service (EKS), Le è mai capitato di imbattersi nel messaggio di errore "Your current user or role does not have access to Kubernetes objects on this EKS cluster"? Un errore decisamente spiazzante, soprattutto quando, da super amministratore globale, ci si sente dire di non avere i diritti. In questo articolo vedremo cosa significa e come risolverlo, passo dopo passo.

"access

Esempio dall'interfaccia della console AWS

"AWS

Esempio dalla CLI kubectl su un cluster EKS

Capire il problema

Per visualizzare le risorse Kubernetes nella AWS Management Console, l'utente o il ruolo IAM AWS deve essere mappato nell'aws-auth``ConfigMap del cluster EKS. Questa mappatura è essenziale: quando un utente crea un cluster EKS, al suo utente o ruolo IAM vengono automaticamente assegnati i permessi system:masters nella configurazione RBAC (Role-Based Access Control) del cluster. È proprio questo che gli permette di vedere le risorse Kubernetes dalla console EKS e di modificare l'aws-auth``ConfigMap all'interno di Kubernetes, abilitando altri utenti o ruoli AWS a interagire con il cluster.

L'utente o il ruolo IAM AWS che crea il cluster, per impostazione predefinita, è l'unico ad avere accesso sia alla AWS Console sia a kubectl. Contrariamente a quanto si potrebbe pensare, il motivo per cui non riesce a visualizzare gli elementi nella AWS Console è proprio l'assenza di una corretta mappatura tra i diritti RBAC di Kubernetes e IAM all'interno dell'aws-auth``ConfigMap.

Come risolvere il problema

Individuare chi ha creato il cluster

Il primo passo è capire chi ha creato il cluster EKS. Un metodo è consultare i log di AWS CloudTrail, che registra tutte le chiamate API AWS, comprese quelle effettuate da AWS Management Console, SDK e CLI. Quindi, se nel Suo account CloudTrail è attivo, dovrebbe poter risalire all'identità di chi ha creato il cluster EKS.

Ecco come procedere passo dopo passo:

Acceda alla AWS Management Console.
Apra CloudTrail dalla AWS Management Console: lo trova digitando 'CloudTrail' nella barra di ricerca dei servizi e selezionandolo dal menu a tendina.
Nella dashboard di CloudTrail, selezioni 'Event history' nella barra laterale.
Nella pagina Event history vedrà i filtri in alto. Imposti il filtro 'Event name' su 'CreateCluster', ovvero la chiamata API che crea un nuovo cluster EKS.
Se conosce il nome del cluster EKS, può anche filtrare per 'Resource name' indicando il nome del cluster.
Una volta applicati i filtri, dovrebbe vedere l'elenco degli eventi 'CreateCluster'. Faccia clic sull'evento per visualizzarne i dettagli: il campo 'User name' indica l'identità dell'utente che ha creato il cluster EKS.

Tenga presente che questo metodo funziona solo se CloudTrail era attivo nell'account AWS al momento della creazione del cluster EKS — cosa che, in genere, avviene per impostazione predefinita. Se così non fosse, non sarà possibile risalire al creatore del cluster EKS. In tal caso, conviene rivolgersi a un amministratore AWS, a un esperto DevOps o SRE, oppure a un altro specialista interno alla Sua organizzazione, che possa aiutarLa a individuare chi ha creato il cluster.

Individuare l'ARN dell'identità IAM

Identifichi l'utente o il ruolo IAM che sta utilizzando per accedere alla console. Può ottenere l'ARN dell'identità IAM eseguendo il seguente comando AWS CLI:

aws sts get-caller-identity --query Arn

Aggiungere un utente o un ruolo IAM all'aws-auth ConfigMap

Per concedere l'accesso al cluster EKS, chi ha creato il cluster può aggiungere un utente o un ruolo IAM all'aws-auth``ConfigMap, in modo che possa interagire con il cluster senza intoppi. Di seguito alcuni esempi su come farlo con kubectl oppure con eksctl:

kubectl

Recuperare il ConfigMap attuale:

kubectl get -n kube-system configmap/aws-auth -o yaml

Questo comando restituirà l'aws-auth``ConfigMap corrente. L'output dovrebbe essere simile a questo:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

2, Per aggiungere un nuovo utente o ruolo IAM, modifichi questo YAML inserendo il nuovo utente o ruolo sotto mapRoles o mapUsers. Ecco un esempio:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::11122223333:role/YourNewRole
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:masters
  mapUsers: |
    - userarn: arn:aws:iam::11122223333:user/YourNewUser
      username: YourNewUser
      groups:
        - system:masters

In questo esempio, sostituisca arn:aws:iam::11122223333:role/YourNewRole con l'ARN del nuovo ruolo IAM e arn:aws:iam::11122223333:user/YourNewUser con l'ARN del nuovo utente IAM. Sostituisca inoltre YourNewUser con il nome del nuovo utente IAM.

3. Una volta apportate le modifiche, applichi il nuovo ConfigMap con il seguente comando:

kubectl apply -f aws-auth-configmap.yaml

Nel comando, sostituisca aws-auth-configmap.yaml con il nome del file del ConfigMap modificato.

eksctl

Per aggiungere un utente IAM:

eksctl create iamidentitymapping --region region-code --cluster cluster-name --arn arn:aws:iam::11122223333:user/YourNewUser --group system:masters

Per aggiungere un ruolo IAM:

eksctl create iamidentitymapping --region region-code --cluster cluster-name --arn arn:aws:iam::11122223333:role/YourNewRole --group system:masters

Negli esempi qui sopra:

Sostituisca region-code con il codice della regione AWS (ad esempio us-west-2).
Sostituisca cluster-name con il nome del cluster EKS.
Sostituisca arn:aws:iam::11122223333:role/YourNewRole con l'ARN del nuovo ruolo IAM e arn:aws:iam::11122223333:user/YourNewUser con l'ARN del nuovo utente IAM.
Sostituisca system:masters con il gruppo Kubernetes appropriato. Per maggiori dettagli, consulti la sezione Kubernetes Groups qui sotto.

Kubernetes Groups

In Kubernetes, un gruppo è un insieme di utenti che condividono gli stessi permessi. Ecco alcuni dei gruppi predefiniti:

system:authenticated: include tutti gli utenti autenticati.
system:unauthenticated: include tutti gli utenti non autenticati.
system:masters: ha pieno accesso al cluster e può eseguire qualunque azione al suo interno. È il gruppo tipicamente associato al ruolo di chi ha creato il cluster.
system:serviceaccounts:<namespace>: include tutti i service account del namespace <namespace>.

Il gruppo system:masters dà pieno accesso al cluster, inclusa la possibilità di creare, leggere, aggiornare ed eliminare qualsiasi risorsa. Proprio per questo, occorre prestare la massima attenzione quando si aggiungono utenti o ruoli a questo gruppo: limiti l'inclusione a utenti o ruoli affidabili e applichi sempre il principio del privilegio minimo, ovvero concedere solo i livelli di accesso o i permessi strettamente necessari a svolgere le attività richieste. È un principio che riduce il rischio di attività malevole o violazioni, restringendo la superficie di attacco.

Problemi di accesso ricorrenti

Se i problemi persistono anche dopo l'aggiornamento dell'aws-auth ConfigMap, la causa potrebbe essere una policy IAM non aggiornata oppure l'RBAC di Kubernetes che non riconosce le modifiche. Come accennato, i permessi IAM sono distinti da quelli di Kubernetes ed entrambi devono essere configurati correttamente affinché l'utente possa interagire con l'API Kubernetes.

Ecco i passaggi da seguire per la risoluzione dei problemi:

Verifichi che l'aws-auth ConfigMap nel namespace kube-system sia stato aggiornato correttamente:

kubectl -n kube-system describe configmap aws-auth

L'output dovrebbe mostrare l'utente o il ruolo IAM sotto mapRoles o mapUsers. Se non compare, significa che il ConfigMap non è stato aggiornato correttamente o che potrebbe essere malformato. Un ConfigMap malformato in Kubernetes equivale a un ConfigMap eliminato, con il rischio concreto di bloccare l'accesso a chiunque tranne a chi ha creato il cluster. Conviene quindi procedere con cautela ed eseguire il linting dello YAML con strumenti come YAML Lint per verificare la configurazione.

2. Verifichi che l'utente o il ruolo IAM sia effettivamente quello aggiunto all'aws-auth``ConfigMap. Un errore di battitura nell'ARN dell'utente o del ruolo IAM è un problema piuttosto comune.

3. Si assicuri che l'utente o il ruolo IAM abbia i permessi AWS necessari, controllando le policy IAM associate. Se deve gestire il cluster EKS e i nodi, le policy AmazonEKSClusterPolicy e AmazonEKSWorkerNodePolicy forniscono i permessi richiesti. Per ulteriori dettagli, consulti la guida AWS managed policies for Amazon Elastic Kubernetes Service.

In alternativa, può creare una policy IAM personalizzata con permessi di sola lettura per le azioni eks:Describe* ed eks:List*, in modo da consentire all'utente o al ruolo di visualizzare le informazioni sulle risorse EKS.

4. Verifichi che l'utente e i gruppi Kubernetes mappati all'entità IAM abbiano i permessi necessari in Kubernetes, facendo riferimento alla guida Kubernetes RBAC roles and bindings.

Si ricordi di applicare sempre il principio del privilegio minimo nell'assegnazione dei permessi, sia in AWS sia in Kubernetes: conceda solo quelli strettamente necessari all'utente o al ruolo per svolgere le proprie attività.

Va sottolineato, infine, che se l'aws-auth ConfigMap viene rimosso, contiene errori di sintassi o è formattato in modo errato, tutti gli utenti tranne chi ha creato il cluster perderanno l'accesso. E sarà soltanto il creatore del cluster a poter rimediare alla situazione.

Muoversi nel complesso panorama degli errori di AWS EKS può non essere semplice, ma con la giusta combinazione di conoscenze, strumenti e buon senso operativo, ogni ostacolo può essere superato. Capire l'intricata interazione tra le identità IAM e Kubernetes è un tassello fondamentale, così come padroneggiare le sfumature nella gestione dell'aws-auth ConfigMap. Ci auguriamo che questa guida Le sia utile, sia che si consideri un veterano di EKS sia che si stia avvicinando per la prima volta alla piattaforma.