В интеграции DataDog CloudTrail отсутствует разрешение ListObject

Question

Сегодня я установил интеграцию DataDog AWS CloudTrail в свою учетную запись AWS (она создает стек CloudFormation и создает, среди прочего, Lambda, которая перенаправляет журналы из ваших журналов CloudTrails в S3 в вашу учетную запись DataDog).

После установки интеграции я вижу ошибку на экране конфигурации DataDog:

      <MY_AWS_ACCOUNT_ID>

management-events - aws-cloudtrail-logs-<redacted>-<redacted>

An error occurred (AccessDenied) when calling the ListObjects operation: Access Denied

Кто-нибудь знает, какие разрешения IAM мне нужно предоставить роли IAM, созданной DataDog (как часть этого стека CF), чтобы она моглаListObjects? Я предполагаю, что это разрешение, связанное с S3?

Я вижу, что стек DataDog также создал для меня корзину S3 с именемdatadogintegration-forwarderstack-forwarderbucket-<redacted>и его текущая политика ведра:

      {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSSLRequestsOnly",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::datadogintegration-forwarderstack-forwarderbucket-<redacted>",
                "arn:aws:s3:::datadogintegration-forwarderstack-forwarderbucket-<redacted>/*"
            ],
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}

Но я не уверен, нужно ли мне вносить изменения в эту политику, разрешение IAM или что-то еще.

Может ли кто-нибудь заметить, где я иду наперекосяк?

Answer 1

Вам нужно будет назначить соответствующую политику роли IAM, созданной Cfn.

Поток будет:

• создать политику
• прикрепите его к своей роли

Политика будет такой: добавьте соответствующие разрешения, если вам нужно больше доступа.

      {
"Version": "2012-10-17",
"Statement": [
    {
        "Action": [
            "s3:ListBucket",
            "s3:GetObject",
            "s3:GetObjectAcl"
        ],
        "Resource": [
             "arn:aws:s3:::<bucketname>",
            "arn:aws:s3:::<bucketname>/*"
        ],
        "Effect": "Allow"
    }
 ]
}

Примечание:

Вы всегда можете проверить свой доступ к роли или службе к определенному ресурсу с помощью симулятора политик AWS.

Вы также можете сделать это с помощью политики ведра, но, на мой взгляд,

      {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "AWS": "arn:aws:iam::ACCOUNT-A:role/xxxx"
                },
                "Action": [
                    "s3:GetObject",
                    "s3:PutObject"
                ],
                "Resource": [
                    "arn:aws:s3:::bucket-name/*"
                ]
            }
        ]
    }

Я использую политику корзины, когда собираюсь столкнуться с тремя подобными ситуациями, хотя вы предпочитаете выбрать политику IAM или политику корзины:

• если единственным сервисом AWS, который вы используете, является S3, вам может быть проще управлять разрешениями непосредственно в S3 с помощью политик корзины.
• где вы можете захотеть использовать политики сегментов, чтобы разрешить доступ из другой учетной записи AWS.
• где вам может понадобиться использовать политики корзин, когда вы хотите разрешить доступ к ресурсам S3 на основе чего-то другого, кроме удостоверения AWS IAM. Например, вы можете ограничить доступ S3 к запросам с определенных IP-адресов. Вы также можете ограничить доступ к медиаресурсам в своей корзине S3 запросами от определенного реферера, чтобы разрешить вашему веб-сайту отображать только изображения и видео.

Поскольку ваша существующая политика корзины применяется, обязательно получите доступ к корзине s3 https, иначе вы не сможете получить доступ.