S3 permissões de balde de conta cruzada

2

Semelhante ao descrito neste artigo [0], a empresa para a qual trabalho usa uma conta do AWS bastion para armazenar usuários do IAM e outras contas da AWS para separar diferentes ambientes em execução (prod, dev etc.). A razão pela qual isso é importante é que temos várias contas da AWS e, em alguns casos exclusivos, essas contas da AWS precisam de acesso a um único intervalo do S3.

Uma maneira de permitir que isso funcione corretamente é definir uma política de buckets que permita o acesso ao bucket a partir do S3 Endpoint de um determinado VPC da conta da AWS.

  1. Política de bucket para data-warehouse

    {
        "Sid": "access-from-dev-VPCE",
        "Effect": "Allow",
        "Principal": "*",
        "Action": "s3:*",
        "Resource": [
            "arn:aws:s3:::data-warehouse",
            "arn:aws:s3:::data-warehouse/*"
        ],
        "Condition": {
            "StringEquals": {
                "aws:sourceVpce": "vpce-d95b05b0"
            }
        }
    }
    
  2. Política de função para a função EMRRole

     {
        "Sid": "AllowRoleToListBucket",
        "Effect": "Allow",
        "Action": "s3:ListBucket",
        "Resource": [
            "arn:aws:s3:::data-warehouse",
        ]
    },
    {
        "Sid": "AllowRoleToGetBucketObjects",
        "Effect": "Allow",
        "Action": [
            "s3:GetObject",
            "s3:GetObjectVersion"
        ],
        "Resource": "arn:aws:s3:::data-warehouse/*"
    }
    

Infelizmente, isso não funciona até que eu defina explicitamente a ACL para cada objeto para permitir o controle total do objeto pelo proprietário da conta da AWS da qual estou acessando. Se eu não fizer isso, obtenho:

fatal error: An error occurred (403) when calling the HeadObject operation: Forbidden

Minha instância em que estou executando isso (EMR) tem o papel correto:

[hadoop@ip-10-137-221-91 tmp]$  aws sts get-caller-identity
{
    "Account": "1234567890",
    "UserId": "AROAIGVIL6ZDI6SR87KXO:i-0eaf8a5ca52876835",
    "Arn": "arn:aws:sts::1234567890:assumed-role/EMRRole/i-0eaf8a5ca52876835"
}

A ACL de um objeto no bloco data-warehouse tem esta aparência:

aws s3api get-object-acl --bucket=data-warehouse --key=content_category/build=2017-11-23/part0000.gz.parquet
{
    "Owner": {
        "DisplayName": "aws+dev",
        "ID": "YXJzdGFyc3RhcnRzadc6frYXJzdGFyc3RhcnN0"
    },
    "Grants": [
        {
            "Grantee": {
                "Type": "CanonicalUser",
                "DisplayName": "aws+dev",
                "ID": "YXJzdGFyc3RhcnRzadc6frYXJzdGFyc3RhcnN0"
            },
            "Permission": "FULL_CONTROL"
        }
    ]
}

Na ACL acima, a conta dev da AWS poderá ler o objeto, mas outra conta da AWS, digamos prod , não poderá ler o objeto até que ele tenha foi adicionado como um "beneficiário".

Minha pergunta: Existe uma maneira de ler / gravar objetos em um bucket S3 de várias contas da AWS sem ter que configurar ACLs em cada objeto individual?

Nota: usamos spark para escrever para s3 usando s3a.

[0] link

    
por c4urself 13.12.2017 / 21:03

1 resposta

0

Embora eu não tenha encontrado uma maneira de definir as ACLs por objeto, existe uma maneira de garantir que as ACLs sejam definidas corretamente no upload usando uma política de bucket. Esta política de exemplo mostra como permitir que uma conta da AWS carregue objetos em seu bucket e exige que o proprietário do bucket receba controle total de todos os objetos carregados:

{
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "AllowSourceAccount0123456789ToPutObjects",
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::0123456789:root"
        },
        "Action": "s3:PutObject",
        "Resource": "arn:aws:s3:::data-warehouse/*"
    },
    {
        "Sid": "RequireAllUploadedObjectsToAssignFullControlToBucketOwner",
        "Effect": "Deny",
        "Principal": {
            "AWS": "*"
        },
        "Action": "s3:PutObject",
        "Resource": "arn:aws:s3:::data-warehouse/*",
        "Condition": {
            "StringNotEquals": {
                "s3:x-amz-acl": "bucket-owner-full-control"
            }
        }
    }
]

}

A chave é a negação explícita que verifica o cabeçalho x-amz-acl: bucket-owner-full-control (mencionado por Michael-sqlbot nos comentários) e falha em qualquer upload onde isso não está definido. Ao usar o AWS CLI para fazer upload de arquivos, isso exige que o sinalizador - acl bucket-owner-full-control seja definido.

Exemplo:

aws s3 cp example-file.txt s3://data-warehouse/example-file.txt --profile aws-profile-name --acl bucket-owner-full-control

Espero que a AWS forneça uma maneira de abordar as ACLs de modo mais elegante em algum momento.

    
por 30.11.2018 / 17:48