Prima o poi uno strumento esterno ti chiede "una chiave di AWS": un pannello di controllo, un sistema di backup, un monitor. La tentazione è copiare la chiave del tuo utente amministratore. Non farlo mai. Chi ha quella chiave può fare tutto quello che puoi fare tu, compreso cancellare l'intero account. La cosa giusta è creare un utente IAM separato con una policy che permetta solo le azioni precise di cui quello strumento ha bisogno, e dargli la sua chiave.
Lo faremo da AWS CloudShell, il terminale integrato nella console web, perché sono quattro comandi da copiare e incollare e il risultato è esatto. Non serve installare nulla sul tuo computer.
Prima di iniziare: cosa significa ogni cosa
- IAM
- Il servizio di AWS che gestisce chi può fare cosa nel tuo account: utenti, chiavi e permessi.
- Utente IAM
- Un'identità dentro il tuo account AWS, diversa dalla tua, a cui dai solo i permessi di cui ha bisogno. Può essere per una persona o per un programma.
- Policy
- L'elenco dei permessi, scritto in un formato di testo chiamato JSON: quali azioni sono permesse e su cosa. La guida te la dà già fatta.
- Chiave di accesso
- Lo "utente e password" per i programmi: due stringhe di testo (identificatore e segreto) che uno strumento usa per parlare con AWS a nome di quell'utente.
- CloudShell
- Un terminale (schermata nera dove si scrivono comandi) integrato nella console web di AWS. Non bisogna installare nulla: si apre ed è già collegato al tuo account.
- Permessi minimi
- L'idea di dare a ogni strumento solo l'indispensabile. Se la chiave trapela, il danno resta limitato a quello.
- ARN
- Il nome completo e unico di qualsiasi cosa in AWS, nella forma arn:aws:... Serve a riferirsi a essa senza equivoci.
- Ruolo
- Un'alternativa all'utente con chiave: lo strumento "prende in prestito" un permesso temporaneo senza che esista una password permanente. Più sicuro, se lo strumento lo ammette.
Passo dopo passo
Decidi quali azioni servono allo strumento
Prima di scrivere qualsiasi cosa, fai la lista. Un pannello che gestisce macchine Lightsail avrà bisogno, per esempio, di: vedere le macchine e il loro stato, avviare, fermare e riavviare, e forse creare e vedere istantanee. Non ha bisogno di creare né cancellare macchine, né di vedere la fatturazione, né di toccare gli utenti. Ogni azione che non è nella lista è un'azione che non darai. Se lo strumento è serio, ti dirà esattamente quali permessi chiede; se ti chiede "AdministratorAccess", diffida.
Apri CloudShell
Nella console di AWS, clicca sull'icona del terminale nella barra superiore (CloudShell) o cercalo per nome. Ci mette qualche secondo ad avviarsi. Hai già un terminale Linux con lo strumento
awsconfigurato con le tue credenziali attuali, quindi tutto ciò che fai lì lo fai come l'utente con cui sei nella console (che deve avere il permesso di gestire IAM).Scrivi la policy
Crea un file con la policy in formato JSON. Questo esempio permette di vedere, avviare, fermare e riavviare macchine Lightsail e gestire le loro istantanee, nient'altro. Incolla il blocco intero in CloudShell:
cat > politica.json <<'FIN' { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "lightsail:GetInstances", "lightsail:GetInstance", "lightsail:GetInstanceState", "lightsail:GetInstanceMetricData", "lightsail:GetRegions", "lightsail:StartInstance", "lightsail:StopInstance", "lightsail:RebootInstance", "lightsail:GetInstanceSnapshots", "lightsail:GetInstanceSnapshot", "lightsail:CreateInstanceSnapshot", "lightsail:DeleteInstanceSnapshot" ], "Resource": "*" }] } FINOgni azione si chiama
servicio:Operación. Se vuoi che lo strumento possa solo vedere, togli le righe di Start, Stop, Reboot, Create e Delete. Per EC2, S3 o RDS le azioni hanno altri nomi, ma la meccanica è identica. In Lightsail la maggior parte delle azioni non si può limitare a una macchina precisa, per questo ilResourceè*; in EC2 o S3 invece puoi indicare l'identificatore esatto della risorsa.Crea la policy, l'utente e collegali
Tre comandi. Cambia il nome se vuoi, ma che dica a cosa serve:
aws iam create-policy --policy-name PanelMaquinas --policy-document file://politica.json aws iam create-user --user-name panel-maquinas CUENTA=$(aws sts get-caller-identity --query Account --output text) aws iam attach-user-policy --user-name panel-maquinas \ --policy-arn arn:aws:iam::$CUENTA:policy/PanelMaquinasIl primo comando restituisce l'ARN della policy; il terzo lo ricostruisce con il numero del tuo account così non devi copiarlo. Nota che all'utente non diamo una password per la console: esisterà solo per la chiave di accesso.
Genera la chiave di accesso
aws iam create-access-key --user-name panel-maquinasLa risposta contiene due valori:
AccessKeyId(inizia con AKIA) eSecretAccessKey. Il segreto viene mostrato solo questa volta. Copialo direttamente nello strumento che lo userà. Non incollarlo in un'email, in una chat né in un documento condiviso. Se lo perdi, non succede nulla: cancelli quella chiave e ne crei un'altra.Cancella il file e verifica
rm politica.json aws iam list-attached-user-policies --user-name panel-maquinasDeve comparire solo
PanelMaquinas. Configura lo strumento con la chiave e prova un'azione permessa (vedere le macchine) e una non permessa (crearne una): la seconda deve fallire con "not authorized". Quell'errore è la prova che hai fatto bene il lavoro.
Cosa può andare storto
Lo strumento dice che non ha il permesso per qualcosa che invece vuoi
Manca un'azione nella policy. Il messaggio di errore di AWS dice esattamente quale (User ... is not authorized to perform: lightsail:GetBundles). Aggiungila al JSON e aggiorna la policy con aws iam create-policy-version --set-as-default, oppure modificala dalla console di IAM. Aggiungi solo quell'azione, non riaprire la mano.
Ho incollato il segreto in un posto dove non dovevo
Consideralo compromesso. In CloudShell: aws iam delete-access-key --user-name panel-maquinas --access-key-id AKIA... e creane un'altra. Siccome l'utente ha permessi minimi, il danno possibile era piccolo; è tutto il senso di questo lavoro.
Il terzo comando fallisce con l'ARN
Può darsi che il tuo utente della console non abbia il permesso per sts:GetCallerIdentity (raro) o che il nome della policy abbia un refuso. Copia l'ARN restituito dal primo comando e incollalo a mano in --policy-arn.
Non sarebbe meglio un ruolo invece di un utente?
Sì, quando lo strumento lo supporta: un ruolo IAM che lo strumento assume dal proprio account AWS non ha nessuna chiave da far trapelare e le credenziali scadono da sole. Chiedi al tuo fornitore se ammette l'"accesso tramite ruolo" o "cross-account role". Se no, l'utente con permessi minimi è la seconda opzione migliore, e molto meglio della chiave di amministratore.
In Simplio
In Simplio non devi scrivere la policy: nell'aiuto spunti con delle caselle cosa vuoi permettere (solo vedere, senza firewall, senza terminale, una regione...) e ti genera il JSON e lo script completo da incollare in CloudShell, che restituisce la chiave già pronta. E se preferisci evitare le chiavi, Simplio ammette la connessione tramite ruolo, con credenziali temporanee che scadono in un'ora. La chiave viene salvata cifrata e non viene mai più mostrata.
La stessa cosa, in AWS e in Simplio
| Nella console di AWS | In Simplio | |
|---|---|---|
| Scrivere la policy | Conoscere il nome esatto di ogni azione di AWS e il formato JSON | Spuntare caselle (solo vedere, senza firewall, senza terminale, una regione): il JSON si genera da solo |
| Creare utente, policy e chiave | CloudShell, 4 comandi, 15 minuti la prima volta | Incollare in CloudShell lo script generato dall'aiuto: 2 minuti |
| Se non vuoi chiavi | Progettare a mano un ruolo tra account | Connessione tramite ruolo con un ARN che Simplio genera per te |