2015-11-24 39 views
8

Per prima cosa, la mia domanda è molto simile a this one, ma poiché non sono riuscito a trovare un "Anche io!" link, ed è stato senza risposta dal 1 ° gennaio, ho pensato che avrei chiesto qui. Per favore fatemi sapere se era la cosa sbagliata da fare.Accesso al bucket AWS S3 da un altro account utilizzando i ruoli

OK, ecco il mio problema. Ho due account AWS, chiamiamoli Prod e Audit. In Prod, ho molte istanze EC2, tutte con i propri specifici ruoli IAM già definiti. In Audit, ho un numero di bucket S3.

Quello che devo essere in grado di fare è, utilizzando solo IAM Ruoli, accedere ai bucket S3 nell'account di controllo da macchine specifiche, utilizzando ruoli IAM specifici, nell'account Prod.

Ho visto molte risposte parlare di Criteri di gruppo, Politiche delle risorse e avere utenti IAM assumere ruoli, ecc., Ma come ho detto, sto usando IAM Ruoli nelle istanze EC2, non ci sono gruppi, utenti, ecc.

Non voglio avere credenziali ovunque su nessuna istanza, ala AWS Best Practices.

Quindi è possibile? C'è un altro modo sicuro per farlo, senza coinvolgere utenti o credenziali? Tutto e molto aiuto molto apprezzato, grazie!

Nota:

L'applicazione in esecuzione sulle istanze EC2 Prod che sto tentando di consentire l'accesso ai secchi Audit S3 è Logstash. Ho confermato che il setup funziona quando si spingono i log verso i bucket Prod S3, solo quelli Audit. Ho anche provato a utilizzare una politica di S3 Bucket senza successo.

La politica benna S3 ho aggiunto è la seguente:

{ 
"Version": "2012-10-17", 
"Statement": [ 
    { 
     "Sid": "CrossAccountPolicy", 
     "Effect": "Allow", 
     "Principal": { 
      "AWS": "arn:aws:iam::<Prod Account ID>:root" 
     }, 
     "Action": "s3:*", 
     "Resource": [ 
      "arn:aws:s3:::logstash.prod.logs", 
      "arn:aws:s3:::logstash.prod.logs/*" 
     ] 
    } 
    ] 
} 

La politica Inline attaccato al ruolo IAM per l'istanza Prod EC2:

{ 
    "Version": "2012-10-17", 
    "Statement": { 
    "Effect": "Allow", 
    "Action": "sts:AssumeRole", 
    "Resource": "arn:aws:iam::<Audit Account ID>:role/ProdLogstashPush" 
    } 
} 

La politica collegata al ruolo IAM in l'account di Audit:

{ 
"Version": "2012-10-17", 
"Statement": [ 
    { 
     "Effect": "Allow", 
     "Action": [ 
      "s3:*" 
     ], 
     "Resource": [ 
      "arn:aws:s3:::logstash.prod.logs/*", 
      "arn:aws:s3:::logstash.prod.logs" 
     ] 
    } 
    ] 
} 

attualmente sto provando fluentd/td-agent perché penso che sia una lows for sts: AssumeRole, che in teoria consentirebbe il funzionamento di questa configurazione.

Dean

+0

sì, la cosa giusta da fare è di sviare quella domanda e aggiungere un commento. ma tu non hai il merito di farlo. :(quindi questa è la prossima cosa migliore –

risposta

2

Sì, è possibile. Credo che puoi farlo utilizzando entrambi i ruoli o una politica del bucket S3. Per riferimento, vedere How IAM Roles Differ from Resource-based Policies, che utilizza uno scenario simile S3 come esempio.

Utilizzo dei ruoli

  1. Nel racconto di controllo, istituito un ruolo più account

    a.) Aggiungere una politica di concessione adeguato accesso in lettura/scrittura ai secchi S3.

    b.) Aggiungere un criterio di attendibilità specificando l'account Prod.

  2. Nel racconto Prod, creare o modificare i ruoli EC2 (profili istanza)

    a.) Consentire le istanze EC2 di chiamare AssumeRole per il ruolo condiviso del conto Audit

    b.) Lasciate che il vostro EC2 istanze da scrivere su S3 (bucket di audit specifico o qualsiasi bucket)

  3. Nell'applicazione, chiamare sts: AssumeRole per ottenere credenziali temporanee da scrivere nel bucket S3 dell'account di controllo. I vari SDK di AWS hanno tutti modi abbastanza semplici ma leggermente diversi di creare nuove credenziali temporanee da un ruolo.

Utilizzando S3 politica benna

È anche possibile fare questo attraverso una politica delle risorse sul secchi S3 dell'account di Audit, di concedere l'accesso all'account Prod, ma senza specificare un particolare utente nel conto Prod . Granting Cross-Account Permissions to Upload Objects While Ensuring the Bucket Owner Has Full Control ha un criterio bucket di esempio per un esempio simile. Un vantaggio di questo approccio è che i ruoli dell'account Prod saranno in grado di scrivere direttamente nel bucket senza dover ottenere le credenziali temporanee da sts: AssumeRole prima. Ci sono due cose da fare:

  1. Nel racconto di verifica, impostare le politiche di secchio S3 per consentire l'accesso all'account Prod. La tua politica del bucket S3 sopra mi sembra OK.

  2. Nell'account Prod, consentire al ruolo del profilo di istanza EC2 di scrivere su S3.

È possibile provare l'AmazonS3FullAccess gestito la politica per il debugging, ma probabilmente si vuole infine specificare le risorse come avete nelle vostre politiche.

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
    { 
     "Effect": "Allow", 
     "Action": "s3:*", 
     "Resource": "*" 
    } 
    ] 
} 
+0

Grazie per la tua risposta e i suggerimenti James! L'applicazione sulle istanze EC2 è logstash, e non è setup (AFAICT) per fare un sts.AssumeRole, quindi è fuori I Ho provato la politica del bucket S3, ma anche con accesso s3. * continuo a ricevere l'accesso negato –

+0

Puoi condividere le politiche che hai usato sia sul bucket Audit che sul ruolo Prod? – James

+0

Spiacente, avrei dovuto farlo subito, aggiungendo –

Problemi correlati