Использование кросс-аккаунта в озере данных AWS S3

Question

У нас есть следующий сценарий: Учетная запись A AWS (приложение) записывает данные из приложения в корзину S3, принадлежащую учетной записи B (озеро данных). Аналитики в учетной записи C (отчетность) хотят обрабатывать данные и создавать на их основе отчеты и информационные панели.

Учетная запись A может записывать данные в озеро данных с --acl bucket-owner-full-control разрешить учетной записи B доступ. Но учетная запись C по-прежнему не может видеть и обрабатывать данные.

Одно (на наш взгляд, плохое) решение - скопировать данные в то же место (перезаписать), что и учетная запись B, эффективно взяв на себя ответственность за данные в процессе и устранить проблему. Мы не хотим этого, потому что... некрасиво

Мы попытались взять на себя роли в разных учетных записях, но это не работает для всей нашей инфраструктуры. Например, доступ S3 через CLI или консоль в порядке, но использование его из EMR в учетной записи C - нет. Также у нас есть локальная инфраструктура (локальные задачи), где этот механизм недоступен.

Поддержание ролей IAM для всех учетных записей и пользователей - это слишком много усилий. Мы стремимся к автоматическому решению, а не к тому, что мы должны предпринимать действия при каждом добавлении нового пользователя или учетной записи.

У вас есть какие-нибудь предложения?

Answer 1

Один хороший и чистый способ заключается в использовании политики корзины, предоставляющей доступ на чтение для внешней учетной записи (учетной записи C), предоставляя учетную запись ARN в качестве принципала.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Sid": "Grant read access to reporting account",
         "Effect": "Allow",
         "Principal": {
            "AWS": "arn:aws:iam::insertReportingAccountIdHere:root"
         },
         "Action": [
            "s3:GetBucketLocation",
            "s3:ListBucket",
            "s3:GetObject",
            "s3:GetObjectAcl"
         ],
         "Resource": [
            "arn:aws:s3:::yourdatalakebucket",
            "arn:aws:s3:::yourdatalakebucket/*"
         ]
      }
   ]
}

Это позволяет учетной записи отчетности управлять разрешениями (ListBucket, gGtObject) для корзины для своих собственных пользователей, что означает, что теперь вы можете создать политику IAM для учетной записи C с разрешением извлекать данные из указанной корзины озера данных:

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Sid": "Allow reading files from the data lake",
         "Effect": "Allow",
         "Action": [
            "s3:GetBucketLocation",
            "s3:ListBucket",
            "s3:GetObject",
            "s3:GetObjectAcl"
         ],
         "Resource": [
            "arn:aws:s3:::yourdatalakebucket",
            "arn:aws:s3:::yourdatalakebucket/*"
         ]
      }
   ]
}

Затем эту политику можно прикрепить к любой роли IAM учетной записи C или группе пользователей. Например, вы можете присоединить его к вашим стандартным ролям "Разработчик" или "Аналитик", чтобы предоставить доступ большим группам пользователей, или вы можете прикрепить его к роли службы, чтобы предоставить определенную службу доступа к корзине.

На сайте документации по Amazon S3 есть руководство, как это сделать.

Answer 2

Вы можете сделать через следующую документацию,

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html

шаги:

1. Создать SAML провайдера
2. Создать роль для поставщика SAML, пример ниже
3. Назначьте роль пользователей на основе условий SAML

Например, вы можете создавать S3 Readers, S3 Writers и назначать разрешения на основании этого.

Пример Предположим Роль с SAML:

{
      "Version": "2012-10-17",
      "Statement": [{
        "Effect": "Allow",
        "Principal": {"Federated": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:saml-provider/ExampleOrgSSOProvider"},
        "Action": "sts:AssumeRoleWithSAML",
        "Condition": {"StringEquals": {
          "saml:edupersonorgdn": "ExampleOrg",
          "saml:aud": "https://signin.aws.amazon.com/saml"
        }}
      }]
}

Надеюсь, поможет.

Answer 3

В нашем случае мы решили ее, используя роли в учетной записи DataLake (B), как для записи (WriterRole), так и для чтения (ReaderRole). При записи в DataLake из учетной записи A ваш писатель предполагает наличие "WriterRole" в учетной записи B, которое имеет необходимые разрешения. При чтении из учетной записи C вы принимаете "ReaderRole". Проблемы с чтением EMR мы решили с помощью EMRFS, используя для чтения роли IAM ( https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html)