AWS IAM - AssumeRole в одном аккаунте?

Я пытаюсь настроить разрешения для рабочего процесса CloudTrail> S3> SQS> Splunk.

https://docs.splunk.com/Documentation/AddOns/released/AWS/ConfigureAWSpermissions

Я создал роль, прикрепил политику для предоставления разрешений для S3, SQS и т. Д.
Я перешел в политику доверительных отношений и добавил тот же номер учетной записи и пользователя, потому что пользователь будет в той же учетной записи.
Затем я перехожу к пользователю и прикрепляю политику для acceptRole, предоставляя имя роли и полный ARN.
Затем я запускаю экземпляр EC2, перехожу к настройке aws, предоставляю доступ, секретные ключи и регион.
Затем я запускаю aws s3 ls или aws s3 list-queues и получаю сообщение об ошибке ниже. Не уверен, что я здесь делаю не так.

Произошла ошибка (AccessDenied) при вызове операции ListBuckets: Доступ запрещен.

Политика Splunk:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sqs:GetQueueAttributes",
                "sqs:ListQueues",
                "sqs:ReceiveMessage",
                "sqs:GetQueueUrl",
                "sqs:DeleteMessage",
                "s3:Get*",
                "s3:List*",
                "s3:Delete*"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Доверительные отношения:

 {   "Version": "2012-10-17",   "Statement": [
     {
       "Effect": "Allow",
       "Principal": {
         "AWS": "arn:aws:iam::XXXXXXXXXXXX:user/username"
       },
       "Action": "sts:AssumeRole",
       "Condition": {}

Политика имени пользователя:

 "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::XXXXXXXXXXXX:role/roleforsplunk"

amazon-web-services

Вам не нужно TrustRelation при принятии роли с той же учетной записи. Удалите его, и он должен работать.

Кстати, не используйте ключи доступа и секретные ключи на инстансах EC2. Вместо этого используйте Роль экземпляра EC2 это даст необходимую завивку вашему процессу Splunk.

Также, вероятно, нет необходимости брать на себя другую роль из роли экземпляра EC2 - просто дайте этой роли необходимую политику / разрешения.

Надеюсь, это поможет :)

Шаг 3 не требуется, поскольку роль IAM будет выполняться пользователем IAM. в одной учетной записи AWS не потребуется явное разрешение sts:AssumeRole разрешение прикреплено к пользователю.

Я думаю, причина, по которой ты получил AccessDenied on ListBuckets внутри вашего экземпляра EC2, потому что учетные данные, используемые для вызова операции ListBuckets, на самом деле являются вашим пользователем IAM, а не самой ролью. Просто настроенный идентификатор ключа доступа / секретный ключ доступа пользователя на шаге 4 не означает, что он автоматически возьмет на себя эту роль за вас. Вы должны ввести команду типа aws sts assume-role чтобы получить временный токен безопасности, представляющий учетные данные роли, которые будут использоваться, или настроить интерфейс командной строки AWS на роль.

Как заявил @MLu, использование идентификатора ключа доступа пользователя IAM / секретного ключа доступа непосредственно в вашем экземпляре EC2 не является хорошей практикой. Рассматривать с использованием профиля экземпляра вместо.

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

За то, что взял на себя роль в разные учетной записи, вам потребуется как политика IAM в из учетная запись, позволяющая sts:AssumeRole для целевой роли И политики доверия для целевой роли, доверяющей «исходной учетной записи» (пользователю «root»)
Чтобы взять на себя роль в той же учетной записи, вы можете либо сделать то же самое, что и в случае перекрестной учетной записи, либо просто добавить из роль в Политике доверия к роль

Из Документация AWS:

Пользователь, который хочет получить доступ к роли в другой учетной записи, также должен иметь разрешения, делегированные администратором учетной записи пользователя. Администратор должен прикрепить политику, которая позволяет пользователю вызывать AssumeRole для ARN роли в другой учетной записи. Если пользователь находится в той же учетной записи, что и роль, вы можете выполнить одно из следующих действий:

Прикрепите к пользователю политику (идентичную предыдущему пользователю в другой учетной записи).

Добавьте пользователя в качестве участника прямо в политику доверия роли.

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

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