Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
aws-iam-authenticator — Uno strumento per utilizzare le credenziali AWS IAM per autenticarsi a un cluster Kubernetes | Kitploit
Strumenti/GitHubGitHub/kubernetes-sigs/aws-iam-authenticator
Autenticazione e AutorizzazioneSicurezza dell'Infrastruttura CloudSicurezza CloudGestione Identità e Accessi (IAM)
GitHubkubernetes-sigs/aws-iam-authenticator

aws-iam-authenticator

Uno strumento per utilizzare le credenziali AWS IAM per autenticarsi a un cluster Kubernetes

Vedi Repository

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi
2.3k4504620 ore faRevisionato da Kitploit

AWS IAM Authenticator per Kubernetes

Uno strumento per utilizzare le credenziali AWS IAM per autenticarsi a un cluster Kubernetes. Il lavoro iniziale su questo strumento è stato guidato da Heptio. Il progetto riceve contributi da diversi ingegneri della community ed è attualmente mantenuto da Heptio e dagli ingegneri OSS di Amazon EKS.

Indice

  • Perché dovrei volerlo?
  • Come lo uso?
  • Utilizzo con Kops
  • Come funziona?
  • Cos'è un cluster ID?
  • Specificare le credenziali e utilizzare i profili AWS
  • Autorizzazione API dall'esterno di un cluster
  • Risoluzione dei problemi
  • Formato completo della configurazione
  • Sviluppo
  • Community, discussione, contribuzione e supporto

Perché dovrei volerlo?

Se sei un amministratore che gestisce un cluster Kubernetes su AWS, devi già gestire le credenziali AWS IAM per effettuare il provisioning e aggiornare il cluster. Utilizzando AWS IAM Authenticator per Kubernetes, eviti di dover gestire una credenziale separata per l'accesso a Kubernetes. AWS IAM fornisce inoltre diverse proprietà utili come una traccia di audit fuori banda (tramite CloudTrail) e l'applicazione di 2FA/MFA.

Se stai realizzando un installer Kubernetes su AWS, AWS IAM Authenticator per Kubernetes può semplificare il tuo processo di bootstrap. Non avrai bisogno di far uscire in modo sicuro e clandestino la tua credenziale amministrativa iniziale dal cluster appena installato. Invece, puoi creare un ruolo dedicato KubernetesAdmin al momento del provisioning del cluster e configurare Authenticator per consentire gli accessi da amministratore del cluster.

Come lo uso?

Supponendo che tu abbia un cluster in esecuzione su AWS e che tu voglia aggiungere il supporto di AWS IAM Authenticator per Kubernetes, devi:

  1. Creare un ruolo IAM che utilizzerai per identificare gli utenti.
  2. Eseguire il server Authenticator come DaemonSet.
  3. Configurare il tuo API server per comunicare con Authenticator.
  4. Configurare kubectl per utilizzare i token di Authenticator.

1. Creare un ruolo IAM

Innanzitutto, devi creare uno o più ruoli IAM che saranno mappati a utenti/gruppi all'interno del tuo cluster Kubernetes. Il modo più semplice per farlo è accedere alla Console AWS:

  • Scegli l'opzione "Role for cross-account access" / "Provide access between AWS accounts you own".
  • Incolla il numero del tuo ID account AWS (disponibile in alto a destra nella console).
  • Il tuo ruolo non necessita di alcuna policy aggiuntiva collegata.

Questo creerà un ruolo IAM senza permessi che può essere assunto da utenti/ruoli autorizzati nel tuo account. Annota l'Amazon Resource Name (ARN) del tuo ruolo, che ti servirà di seguito.

Puoi anche farlo in un unico passaggio utilizzando la AWS CLI invece della Console AWS:

# get your account ID
ACCOUNT_ID=$(aws sts get-caller-identity --output text --query 'Account')

# define a role trust policy that opens the role to users in your account (limited by IAM policy)
POLICY=$(echo -n '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::'; echo -n "$ACCOUNT_ID"; echo -n ':root"},"Action":"sts:AssumeRole","Condition":{}}]}')

# create a role named KubernetesAdmin (will print the new role's ARN)
aws iam create-role \
  --role-name KubernetesAdmin \
  --description "Kubernetes administrator role (for AWS IAM Authenticator for Kubernetes)." \
  --assume-role-policy-document "$POLICY" \
  --output text \
  --query 'Role.Arn'

Puoi anche saltare questo passaggio e utilizzare:

  • Un ruolo esistente (come un ruolo di accesso cross-account).
  • Un utente IAM (vedi mapUsers di seguito).
  • Un'istanza EC2 o un ruolo federato (vedi mapRoles di seguito).

2. Avvia il server

Il server è pensato per essere eseguito su ciascuno dei tuoi nodi master come DaemonSet con host networking, in modo da poter esporre una porta localhost.

Per un esempio di configurazione ConfigMap e DaemonSet, vedi deploy/example.yaml. Prima di applicarla, aggiorna questi valori per il tuo cluster:

  • Sostituisci gli ARN IAM segnaposto (arn:aws:iam::000000000000:...) in config.yaml.
  • Imposta clusterID su un valore univoco per il tuo cluster.
  • Verifica che le regole di scheduling del DaemonSet corrispondano alle etichette/taint dei tuoi nodi control-plane.

Poi distribuiscilo:

kubectl apply -f deploy/example.yaml
kubectl -n kube-system rollout status daemonset/aws-iam-authenticator
kubectl -n kube-system get pods -l k8s-app=aws-iam-authenticator

Una volta che il pod è in esecuzione su un nodo control-plane, aws-iam-authenticator server creerà il kubeconfig del webhook sull'host in /etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml (o nel percorso configurato tramite --generate-kubeconfig).

(Opzionale) Pre-generare un certificato, una chiave e un kubeconfig

Se stai realizzando un installer automatizzato, puoi anche pre-generare facilmente i file del certificato, della chiave e del kubeconfig del webhook usando aws-iam-authenticator init. Questo comando genererà i file e li collocherà nelle directory di output configurate.

Puoi eseguirlo su ciascun master node prima di avviare l'API server. Potresti anche generarli prima del provisioning dei master node e installarli nei percorsi host appropriati.

Se non pre-generi i file, aws-iam-authenticator server li genererà su richiesta. Questo funziona ma richiede il riavvio del tuo Kubernetes API server dopo l'installazione.

3. Configura il tuo API server per comunicare con il server

L'API di Kubernetes si integra con AWS IAM Authenticator for Kubernetes tramite un webhook di autenticazione tramite token. Quando esegui aws-iam-authenticator server, questo genererà un file di configurazione del webhook e lo salverà sul filesystem dell'host. Dovrai aggiungere un singolo flag aggiuntivo alla configurazione del tuo API server:

--authentication-token-webhook-config-file=/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml

Su molti cluster, il server API viene eseguito come pod statico. Puoi aggiungere il flag a /etc/kubernetes/manifests/kube-apiserver.yaml. Assicurati che la directory host /etc/kubernetes/aws-iam-authenticator/ sia montata nel tuo pod del server API. Potrebbe anche essere necessario riavviare il demone kubelet sul nodo master per recepire la definizione aggiornata del pod statico:

systemctl restart kubelet.service

4. Creare le mappature tra ruolo/utente IAM e utente/gruppo Kubernetes

Il comportamento predefinito del server è di ottenere le mappature esclusivamente dai campi mapUsers e mapRoles del suo file di configurazione. Vedere Formato completo della configurazione di seguito per i dettagli.

Utilizzando il flag --backend-mode, è possibile configurare il server per ottenere le mappature da due backend aggiuntivi: una ConfigMap in stile EKS (--backend-mode=EKSConfigMap) o risorse personalizzate IAMIdentityMapping (--backend-mode=CRD). Il backend predefinito, il file di configurazione del server montato dal pod del server, corrisponde a --backend-mode=MountedFile.

Scarica lo strumento