Qual è il metodo migliore per passare le credenziali AWS come dati utente a un'istanza EC2?

StackOverflow https://stackoverflow.com/questions/640838

Domanda

Ho un'architettura di elaborazione dei lavori basata su AWS che richiede query di istanze EC2 S3 e SQS. Affinché le istanze in esecuzione abbiano accesso all'API, le credenziali vengono inviate come dati utente (-f) sotto forma di uno script shell codificato in base64. Ad esempio: 

$ cat ec2.sh
...
export AWS_ACCOUNT_NUMBER='1111-1111-1111'
export AWS_ACCESS_KEY_ID='0x0x0x0x0x0x0x0x0x0'
...
$ zip -P 'secret-password' ec2.sh
$ openssl enc -base64 -in ec2.zip

Vengono lanciate molte istanze ... 

$ ec2run ami-a83fabc0 -n 20 -f ec2.zip

Ogni istanza decodifica e decodifica ec2.zip usando la 'password segreta' che è codificata in uno script init. Sebbene funzioni, ho due problemi con il mio approccio.

  1. 'zip -P' non è molto sicuro
  2. La password è codificata nell'istanza (è sempre "password segreta")

Il metodo è molto simile a quello descritto qui

Esiste un approccio più elegante o accettato? Usare gpg per crittografare le credenziali e archiviare la chiave privata sull'istanza per decrittografare è un approccio che sto prendendo in considerazione ora ma non sono a conoscenza di alcun avvertimento. Posso usare direttamente le coppie di chiavi AWS? Mi sto perdendo una parte super ovvia dell'API?

È stato utile?

Soluzione

È possibile archiviare le credenziali sulla macchina (o trasferire, utilizzare, quindi rimuoverle.)

È possibile trasferire le credenziali su un canale sicuro (ad es. utilizzando scp con autenticazione non interattiva ad es. coppia di chiavi) in modo da non dover eseguire alcuna crittografia personalizzata (assicurarsi solo che le autorizzazioni siano correttamente impostato su 0400 sul file chiave in ogni momento, ad esempio impostare le autorizzazioni sui file master e utilizzare scp -p )

Se quanto sopra non risponde alla tua domanda, ti preghiamo di fornire dettagli più specifici riguardo a. qual è la tua configurazione e cosa stai cercando di ottenere. Le azioni EC2 devono essere avviate su più nodi da una posizione centrale? SSH è disponibile tra più nodi e la posizione centrale? Ecc.

Modifica

Hai preso in considerazione parametrizzare la tua AMI , richiedendo a coloro che istanziano il tuo AMI per popolare innanzitutto i dati utente ( istanze ec2 -f-file-dati-utente ) con le loro chiavi AWS? L'AMI può quindi recuperare dinamicamente questi parametri per istanza da http://169.254.169.254/1.0/user-data .

Aggiorna

OK, ecco un confronto attento alla sicurezza dei vari approcci discussi finora:

  1. Sicurezza dei dati quando archiviati nel dati utente AMI non codificati
    • low
    • i dati in chiaro sono accessibili a qualsiasi utente che riesce ad accedere all'AMI e ha accesso a telnet , curl , wget , ecc. (può accedere a in chiaro http://169.254.169.254/1.0/user-data )
    • sei vulnerabile agli attacchi di richieste proxy (ad es. un utente malintenzionato chiede ad Apache che potrebbe essere o meno in esecuzione sull'AMI per ottenere e inoltrare il in chiaro http://169.254.169.254/1.0/user-data )
  2. Sicurezza dei dati quando archiviati nell'AMI dati utente e crittografati (o decodificabili) con chiave facilmente ottenibile
    • low
    • chiave facilmente reperibile (password) può includere:
      • chiave hardcoded in uno script all'interno di un ABI (dove l'ABI può essere ottenuto da un attaccante)
      • chiave hardcoded in uno script sull'AMI stesso, in cui lo script è leggibile da qualsiasi utente che riesce ad accedere all'AMI
      • qualsiasi altra informazione facilmente ottenibile come chiavi pubbliche, ecc.
      • qualsiasi chiave privata (la sua chiave pubblica può essere facilmente ottenibile)
    • data una chiave facilmente ottenibile (password), si applicano gli stessi problemi identificati al punto 1, vale a dire:
      • i dati decrittografati sono accessibili a qualsiasi utente che riesce ad accedere all'AMI e ha accesso a telnet , curl , wget , ecc. (può accedere a in chiaro http://169.254.169.254/1.0/user-data )
      • sei vulnerabile agli attacchi di richieste proxy (ad es. l'attaccante chiede all'Apache che potrebbe o non potrebbe essere in esecuzione sull'AMI di ottenere e inoltrare il crittografato http://169.254.169.254/1.0/user-data, ulteriormente descritto con la chiave facilmente ottenibile)
  3. Sicurezza dei dati quando archiviati nel dati utente AMI e crittografati con chiave non facilmente ottenibile
    • medio
    • i dati crittografati sono accessibili a qualsiasi utente che riesce ad accedere all'AMI e ha accesso a telnet , curl , wget , ecc. (può accedere a crittografato http://169.254.169.254/1.0/user-data )
      • è quindi possibile effettuare un tentativo di decrittografia dei dati crittografati mediante attacchi di forza bruta
  4. Sicurezza dei dati quando archiviati sull'AMI, in una posizione protetta (nessun valore aggiunto per la crittografia

Altri suggerimenti

Ho scritto un articolo che esamina vari metodi per passare i segreti a un'istanza EC2 in modo sicuro e i professionisti & amp; contro di ciascuno.

http: // www.shlomoswidler.com/2009/08/how-to-keep-your-aws-credentials-on-ec2.html

Il modo migliore è utilizzare profili di istanza . L'idea di base è:

  • Crea un profilo di istanza
  • Crea un nuovo ruolo IAM

  • Assegna una politica al ruolo precedentemente creato, ad esempio:

    {   "Dichiarazione": [     {       " Sid " ;: " Stmt1369049349504 " ;,       " Azione " ;: " sqs: " ;,       " Effect " ;: " Allow " ;,       " Resource " ;: " "     }   ] }

  • Associa insieme il ruolo e il profilo dell'istanza.

  • Quando si avvia una nuova istanza EC2, assicurarsi di fornire il nome del profilo dell'istanza.

Se tutto funziona correttamente e la libreria utilizzata per connettersi ai servizi AWS dall'istanza EC2 supporta il recupero delle credenziali dai metadati dell'istanza, il codice sarà in grado di utilizzare i servizi AWS.

Un esempio completo tratto dalla mailing list di boto-user:

Innanzitutto, è necessario creare un documento della politica JSON che rappresenti a quali servizi e risorse dovrebbe accedere il ruolo IAM. ad esempio, questa politica garantisce tutte le azioni S3 per il bucket " my_bucket " ;. Puoi utilizzare qualsiasi politica sia appropriata per la tua applicazione. 

BUCKET_POLICY = """{
  "Statement":[{
    "Effect":"Allow",
    "Action":["s3:*"],
    "Resource":["arn:aws:s3:::my_bucket"]}]}"""

Successivamente, è necessario creare un profilo istanza in IAM. 

import boto
c = boto.connect_iam()
instance_profile = c.create_instance_profile('myinstanceprofile')

Una volta ottenuto il profilo dell'istanza, è necessario creare il ruolo, aggiungere il ruolo al profilo dell'istanza e associare la politica al ruolo. 

role = c.create_role('myrole')
c.add_role_to_instance_profile('myinstanceprofile', 'myrole')
c.put_role_policy('myrole', 'mypolicy', BUCKET_POLICY)

Ora puoi utilizzare quel profilo di istanza quando avvii un'istanza: 

ec2 = boto.connect_ec2()
ec2.run_instances('ami-xxxxxxx', ..., instance_profile_name='myinstanceprofile')

Vorrei sottolineare che non è più necessario fornire credenziali all'istanza EC2. Usando IAM, puoi creare un ruolo per le tue istanze EC2. In questi ruoli, è possibile impostare criteri dettagliati che consentono all'istanza EC2 di ottenere, ad esempio, un oggetto specifico da un bucket S3 specifico e non di più. Puoi leggere ulteriori informazioni sui ruoli IAM nei documenti AWS:

http://docs.aws.amazon.com/IAM/ ultima / UserGuide / WorkingWithRoles.html

Come altri hanno già sottolineato qui, non è davvero necessario archiviare le credenziali AWS per un'istanza EC2, utilizzando IAM Roles -   https: // aws .amazon.com / blog / security / a-sicuro-way-to-distribute-AWS-credenziali-to-EC2 / . Aggiungerò che puoi utilizzare lo stesso metodo anche per archiviare in modo sicuro credenziali NON AWS ?? per la tua istanza EC2, come dire se hai alcune credenziali db che vuoi mantenere al sicuro. Salvare le credenziali non aws su un Bukcet S3 e utilizzare il ruolo IAM per accedere a quel bucket. puoi trovare informazioni più dettagliate su questo qui - https://aws.amazon.com/blogs/security/using-iam-roles-to-distribute-non-aws-credentials-to-your-ec2-instances/

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top