Доступ к ковру AWS S3 с другого аккаунта с использованием ролей

Question

Прежде всего, мой вопрос очень похож на this one, но так как я не мог найти «Я тоже!». link, и с 1 января он остался без ответа, я думал, что попрошу здесь. Пожалуйста, дайте мне знать, если это не так.

OK, поэтому здесь моя проблема. У меня есть две учетные записи AWS, которые называют их Prod и Audit. В Prod у меня есть много экземпляров EC2, все из которых имеют свои собственные определенные классы IAM. В аудите у меня есть несколько ведер S3.

Что нужно сделать, используя только роли IAM, получить доступ к ведрам S3 в учетной записи аудита с определенных компьютеров с использованием определенных ролей IAM в учетной записи Prod.

Я видел много ответов о групповых политиках, политике ресурсов и о том, что пользователи IAM принимают роли и т. Д., Но, как я уже сказал, я использую роли IAM на экземплярах EC2, нет групп, пользователей и т. Д.

Я не хочу иметь учетные данные нигде в любом из экземпляров, ala AWS Best Practices.

Это возможно? Есть ли другой безопасный способ сделать это без привлечения пользователей или учетных данных? Любая помощь очень ценится, спасибо!

Примечание:

Приложение работает на EC2 случаях Prod, что я пытаюсь разрешить доступ к ведрам аудита S3 является Logstash. Я подтвердил, что настройка работает при нажатии журналов на ведра Prod S3, а не на аудит. Я также пробовал использовать S3 Bucket Policy, и успеха там не было.

модель S3 Ковш политики Я добавил выглядят следующим образом:

{ 
"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/*" 
     ] 
    } 
    ] 
} 

Политика Инлайн прикреплен к IAM роли для экземпляра Прода EC2:

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

Политики прикрепленной к IAM роли в Аудиторский счет:

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

Я в настоящее время пытаюсь использовать fluentd/td-agent, потому что я думаю, что это для sts: AssumeRole, который теоретически позволит этой установке работать.

Dean

Answer 1

Да, это возможно. Я считаю, что вы можете сделать это, используя либо роли, либо политику ведомости S3. Для справки см. How IAM Roles Differ from Resource-based Policies, в котором в качестве примера используется аналогичный сценарий S3.

Использование Роли

1. В счет аудита, установить роль кросс-счета

   а.) Добавить политику предоставления надлежащего доступа на чтение/запись к ведер S3.

   b.) Добавить политику доверия, определяющую учетную запись Prod.

2. В Prod счете, создавать или изменять свои роли EC2 (профили экземпляра)

   а.) Разрешить экземпляры EC2 для вызова AssumeRole для общей роли аудита счета

   б.) Позвольте ваши EC2 экземпляры для записи на S3 (конкретный аудиторский ковш или любой ковш)

3. В вашем приложении вызовите sts: AssumeRole, чтобы получить временные учетные данные для записи в ведомость учетной записи S3. Различные AWS SDK имеют довольно простые, но несколько разные способы создания новых временных учетных данных из роли.

Использование S3 Bucket политики

Вы также можете сделать это с помощью политики ресурсов на S3 ведрами по аудиту аккаунта, предоставление доступа к Prod счету, но не указывая конкретного пользователя в Prod учетной записи , Granting Cross-Account Permissions to Upload Objects While Ensuring the Bucket Owner Has Full Control имеет пример политики ведра для аналогичного примера. Преимущество такого подхода заключается в том, что ваши роли в учетной записи Prod смогут записывать непосредственно в ведро без необходимости получения временных учетных данных из sts: сначала AssumeRole. Есть две вещи:

1. В учетной записи аудита задайте политики корзины S3, чтобы разрешить доступ к учетной записи Prod. Ваша политика корзины S3 выше выглядит нормально для меня.

2. В учетной записи Prod разрешить роль профиля экземпляра EC2 записывать на S3.

Вы можете попробовать AmazonS3FullAccess удался политика для отладки, но вы, вероятно, хотите, чтобы в конечном итоге указать ресурсы, как у вас есть в вашей политике.

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