☰

Permisos de depósitos entre cuentas de S3

tag-icon • tag-icon amazon-s3 apache-spark
Permisos de depósitos entre cuentas de S3

De manera similar a lo que se describe en este artículo[0], la empresa para la que trabajo utiliza una cuenta bastión de AWS para almacenar usuarios de IAM y otras cuentas de AWS para separar diferentes entornos de ejecución (producción, desarrollo, etc.). La razón por la que esto es importante es que tenemos varias cuentas de AWS y, en algunos casos únicos, estas cuentas de AWS necesitan acceso a un único depósito de S3.

Una forma de permitir que esto funcione correctamente es establecer una política de depósito que permita el acceso al depósito desde el punto final S3 desde la VPC de una cuenta de AWS en particular.

  1. Política de depósito paradata-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 rol para rolEMRRole

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

Lamentablemente, esto no funciona hasta que haya configurado explícitamente la ACL paracada objetopara permitir el control total de ese objeto por parte del propietario de la cuenta de AWS desde la que accedo. Si no hago esto, obtengo:

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

Mi instancia en la que estoy ejecutando esto (EMR) tiene la función correcta:

[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"
}

La ACL para un objeto en el data-warehousedepósito tiene este aspecto:

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"
        }
    ]
}

En la ACL anterior, la devcuenta de AWS podrá leer el objeto, pero otra cuenta de AWS, por ejemplo prod, lo hará.nopodrá leer el objeto hasta que se haya agregado como "beneficiario".

Mi pregunta:¿Existe alguna forma de leer/escribir objetos en un depósito S3 desde varias cuentas de AWS sin tener que configurar ACL en cada objeto individual?

Nota: usamos Spark para escribir en s3 usando s3a.

[0]https://engineering.coinbase.com/you-need-more-than-one-aws-account-aws-bastions-and-assume-role-23946c6dfde3

Respuesta1

Si bien no he encontrado una manera de configurar las ACL por objeto, existe una manera de hacer cumplir que las ACL estén configuradas correctamente en la carga mediante una política de depósito. Esta política de ejemplo muestra cómo permitir que una cuenta de AWS cargue objetos en su depósito y requiere que el propietario del depósito tenga control total de todos los objetos cargados:

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

}

La clave es la denegación explícita que comprueba lax-amz-acl: bucket-owner-full-control encabezado (mencionado por Michael-sqlbot en los comentarios) y falla cualquier carga donde no esté configurado. Cuando se utiliza la AWS CLI para cargar archivos, esto requiere la--acl control-total-propietario-del-depósitobandera que se va a establecer.

Ejemplo:

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

Con suerte, AWS proporcionará una manera de abordar las ACL de manera más elegante en algún momento.

información relacionada