Политика S3 Bucket, как разрешить группу IAM из другой учетной записи?

У меня есть одна корзина S3 в одной учетной записи AWS (скажем, arn:aws:s3:::my-test-bucket), к которой должен получить доступ группа IAM, определенная в другой учетной записи AWS (скажем, arn:aws:iam::1111222333444:group/mygroup). Следующая политика доступа отказывается сохранять и сообщает, что arn:aws:s3:::my-test-bucket является недействительным принципалом.

{
    "Statement": [
        {
            "Action": [
                "s3:ListBucket",
                "s3:PutObject",
                "s3:List*",
                "s3:Get*"
            ],
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::1111222333444:group/mygroup"
            },
            "Resource": [
                "arn:aws:s3:::my-test-bucket",
                "arn:aws:s3:::my-test-bucket/*"
            ],
            "Sid": "allow-put-for-dedicated-group"
        }
    ],
}

Я проверил, заменив группу одним из пользователей другой учетной записи, и это работает:

{
    "Statement": [
        {
            "Action": [
                "s3:ListBucket",
                "s3:PutObject",
                "s3:List*",
                "s3:Get*"
            ],
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::1111222333444:user/me"
            },
            "Resource": [
                "arn:aws:s3:::my-test-bucket",
                "arn:aws:s3:::my-test-bucket/*"
            ],
            "Sid": "allow-put-for-dedicated-user"
        }
    ],
}

Группа существует, я не понимаю, почему она говорит, что это недопустимый принципал. На самом деле он не принимает ни одну группу моего другого аккаунта.

У кого-нибудь есть объяснение (и, возможно, решение) этого поведения?

Заранее спасибо

Источник

2 ответа

Решение

Группы IAM не являются действительными принципалами в политиках сегмента S3. См. Этот пост на форуме AWS и этот пост для дальнейшего обсуждения.

Источник

Как сказал jarmod, группы IAM не являются действительными принципами. Также будет работать решение jarmod. Однако можно сослаться на роль, предполагаемую политикой корзины S3. Это позволяет вам запрещать действия, если они не выполняются этой ролью, что затем обеспечивает видимость того, кто имеет доступ, который вы хотели, или может быть использован для дальнейшего ограничения предоставленного доступа. Ссылка на роль осуществляется через идентификатор роли, который можно получить с помощью следующей команды интерфейса командной строки AWS :aws iam get-role --role-name ROLE_NAME --profile PROFILE_NAME, где ROLE_NAME — имя роли, созданной с помощьюsts:AssumeRoleа PROFILE_NAME — это настройка профиля AWS для доступа к роли.

Затем для политики корзины S3 можно использовать что-то вроде следующего:

      {
    "Statement": [
        {
            "Action": [
                "s3:ListBucket",
                "s3:PutObject",
                "s3:List*",
                "s3:Get*"
            ],
            "Effect": "Deny",
            "Principal": "*"
            "Resource": [
                "arn:aws:s3:::my-test-bucket",
                "arn:aws:s3:::my-test-bucket/*"
            ],
            "Sid": "deny-put-for-anyone-but-dedicated-role",
            "Condition": {
                "StringNotLike": {
                    "aws:userId": [
                        "ROLE_ID:*"
                    ]
                }
            }
        }
    ],
}

Более подробную информацию об этом можно найти в этом сообщении в блоге , которое включает использование userId для ограничения доступа к пользователю.

Источник
Другие вопросы по тегам