Всегда ли я должен брать на себя роль для доступа к S3? - PullRequest
Новая
       6

Всегда ли я должен брать на себя роль для доступа к S3?

1 голос
/ 03 апреля 2020

Я пытаюсь настроить кросс-аккаунт S3. Моя учетная запись A имеет доступ к файлам в расположении S3 учетной записи B. Я сделал следующие шаги:

  1. Роль B IAM была создана в учетной записи B с доступом к расположению S3
  2. Роль A IAM была создана в учетной записи A, которую мы будем использовать для принятия роли B
  3. Роль B добавила учетную запись A к своим доверенным отношениям и предоставила разрешения KMS
  4. Роль A добавила встроенные политики разрешений для принятия роли B и использования ключа KMS

Я могу получить доступ к файлам S3, явно взяв на себя роль учетной записи B, используя следующий код: 

client = boto3.client('sts')
response = client.assume_role(RoleArn=source_role, RoleSessionName='cross_account_session',DurationSeconds=3600)
credentials = response['Credentials']

Есть ли способ настроить это, чтобы мне не приходилось явно брать на себя роль? то есть, учитывая, что доверительные отношения уже установлены, если я использую учетную запись A и пытаюсь получить доступ к корзине S3 учетной записи B, могут ли разрешения автоматически предоставляться без необходимости вызова client.assume_role()?

Ответы [ 2 ]

2 голосов
/ 03 апреля 2020

Еще один вариант, который у вас есть, - это добавить политику сегмента S3 в корзину назначения, предоставляя доступ к указанному c пользователю IAM (или роли IAM) в исходной учетной записи AWS. Например: 

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"melissalist",
      "Effect":"Allow",
      "Principal": { "AWS": "arn:aws:iam::999999999999:user/melissa" },
      "Action":["s3:List*"],
      "Resource":["arn:aws:s3:::mybucket"]
    },
    {
      "Sid":"melissaget",
      "Effect":"Allow",
      "Principal": { "AWS": "arn:aws:iam::999999999999:user/melissa" },
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::mybucket/*"]
    }
  ]
}

Вы можете найти исходный идентификатор IAM в консоли AWS IAM или использовать awscli : 

aws sts get-caller-identity

Результаты : 

{
  "UserId": "AIDAAAAAAAAAAAAAAAAAA",
  "Account": "999999999999",
  "Arn": "arn:aws:iam::999999999999:user/melissa"
}
0 голосов
/ 03 апреля 2020

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

Но для рассматриваемого сценария, то есть доступа к нескольким учетным записям для зашифрованного KMS S3 Bucket, допущение роли можно пропустить, предоставив доступ к S3 и KMS с помощью политик ресурсов.

В учетной записи B добавьте эту политику Bucket в корзину S3 

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"CrossAccountReadAccess",
      "Effect":"Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::<AccountA-ID>:root"
         ]   
      },
      "Action":[
             "s3:GetObject",
             "s3:GetBucketLocation",
             "s3:ListBucket"
      ],
      "Resource":[
         "arn:aws:s3:::bucketname",
         "arn:aws:s3:::bucketname/*"
       ]
    }
  ]
}

В учетной записи B добавьте эту Политику ключей к ключу KMS, используемому для шифрования объектов 

{
    "Sid": "CrossAccountDecryptAccess",
    "Effect": "Allow",
    "Principal": {
       "AWS": [
         "arn:aws:iam::<AccountA-ID>:root" 
       ]
    },
    "Action": [
        "kms:Decrypt",
        "kms:DescribeKey",
        "kms:GenerateDataKey*"
    ],
    "Resource": "*"
}

Principal упоминается как root для обеих политик, измените его, чтобы ограничить его любой пользователь IAM в учетной записи A.

и для этого пользователя в учетной записи A обновите политику IAM, чтобы разрешить соответствующий доступ S3 и KMS.

Примечание : Политики ресурсов определены здесь только для доступа для чтения. Обновите Action в заявлениях политики, чтобы предоставить больше доступа при необходимости.

ВНИМАНИЕ: Если предоставлены права на запись, объекты, написанные с помощью учетной записи A, будут принадлежать только учетной записи A. bucket-owner-full-control ACL должен быть явно добавлен к этим объектам, чтобы учетная запись B могла получить к ним доступ.

...