Политика AWS CloudFormation IAM и политика SQS, похоже, имеют аналогичные настройки, но не уверены, почему?

Question

Я новичок в AWS CloudFormation, и я пытаюсь выяснить некоторые ранее существовавшие CloudSormation JSON. Я читал документацию много раз, но, похоже, у меня больше вопросов, чем ответов.

Ниже приведена модифицированная версия моего файла CloudFormation. Я попытался вырезать как можно больше из примера CloudFormation, чтобы, надеюсь, уменьшить визуальный шум. Я ценю, что читатели не будут знать причины, по которым делаются определенные вещи, но я надеюсь, что мои вопросы (см. Ниже) осветят более фундаментальную проблему с тем, как CF был написан.

CF JSON создает очередь SQS, политику очереди SQS и политику IAM.

Политика очереди SQS обеспечивает полный доступ к API в очередь SQS (также ограничивает доступ к определенным IP-адресам через условие) и, как представляется, назначает эти разрешения самой очереди.

Но у нас также есть политика IAM, которая, похоже, делает подобную вещь? Он назначает определенные разрешения очереди SQS, но на этот раз для роли, а не для самой очереди, как, например, для политики очередей SQS.

Мой вопрос, почему дублирование? Могли бы мы просто не иметь разрешения доступа, применяемые к политике очереди SQS, и просто удалить политику IAM «QueuesPolicy»?

Я могу понять, почему политика IAM «QueuesPolicy» будет устанавливать разрешения доступа к очереди SQS: потому что вы могли бы иметь несколько ролей, получающих доступ к одной очереди, и вы хотите, чтобы у них был другой набор разрешений (а не в очереди с конкретный набор разрешений для всех ролей). Но если это так, то почему у вас тоже есть разрешения? Это похоже на ошибку или используется как «откат»?

Я также предполагал, что мы могли бы сохранить политику очереди SQS, но просто удалить разрешения API и сохранить возможность ограничить свой собственный доступ к определенным IP-адресам. Будет ли это работать в этом примере?

Кроме того, AWS :: IAM :: Role смущает меня, потому что я не совсем уверен, что понимаю, что он делает. Кажется, что экземпляр EC2 будет иметь возможность принять FooRole, это правильно? Я предполагаю, что, поскольку у нас есть один набор учетных данных AWS, приложение, запущенное на экземпляре EC2, вполне может использовать учетные данные для доступа к нашей учетной записи AWS, но поскольку нет отдельных «пользователей», мы должны были бы нуждаться в, чтобы иметь роль и экземпляр EC2 имеет доступ к этой роли для запроса (например, для отправки сообщения в очередь из приложения) для авторизации?

{ 
    "AWSTemplateFormatVersion": "2010-09-09", 
    "Resources": { 
    "EC2ComponentPolicy": { 
     "Type": "AWS::IAM::Policy", 
     "Properties": { 
     "PolicyName": "EC2ComponentPolicy", 
     "PolicyDocument": { 
      "Statement": [ 
      { 
       "Action": [ 
       "cloudformation:Describe*" 
       ], 
       "Resource": [ 
       "*" 
       ], 
       "Effect": "Allow" 
      }, 
      { 
       "Action": [ 
       "ec2:Describe*" 
       ], 
       "Resource": [ 
       "*" 
       ], 
       "Effect": "Allow" 
      } 
      ] 
     }, 
     "Roles": [ 
      { 
      "Ref": "FooRole" 
      } 
     ] 
     } 
    }, 
    "SQSFooQueue": { 
     "Type": "AWS::SQS::Queue", 
     "Properties": { 
     "MessageRetentionPeriod": 86400, 
     "VisibilityTimeout": { 
      "Ref": "VisibilityTimeout" 
     } 
     } 
    }, 
    "ComponentInstanceProfile": { 
     "Type": "AWS::IAM::InstanceProfile", 
     "Properties": { 
     "Path": "/", 
     "Roles": [ 
      { 
      "Ref": "FooRole" 
      } 
     ] 
     } 
    }, 
    "SQSFooQueuePolicy": { 
     "Type": "AWS::SQS::QueuePolicy", 
     "Properties": { 
     "Queues": [ 
      { 
      "Ref": "SQSFooQueue" 
      } 
     ], 
     "PolicyDocument": { 
      "Version": "2012-10-17", 
      "Id": "SQSFooQueuePolicy", 
      "Statement": [ 
      { 
       "Resource": [ 
       { 
        "Fn::GetAtt": [ 
        "SQSFooQueue", 
        "Arn" 
        ] 
       } 
       ], 
       "Effect": "Allow", 
       "Sid": "Allow-User-SendMessage", 
       "Action": [ 
       "sqs:*" 
       ], 
       "Condition": { 
       "IpAddress": { 
        "aws:SourceIp": [ 
        "xxx.xx.xxx.x/xx", 
        "xxx.xx.xxx.x/xx", 
        "xxx.xx.xxx.x/xx" 
        ] 
       } 
       }, 
       "Principal": { 
       "AWS": "*" 
       } 
      } 
      ] 
     } 
     } 
    }, 
    "QueuesPolicy": { 
     "Type": "AWS::IAM::Policy", 
     "Properties": { 
     "PolicyName": "QueuesPolicy", 
     "PolicyDocument": { 
      "Statement": [ 
      { 
       "Action": [ 
       "sqs:AddPermission", 
       "sqs:ChangeMessageVisibility", 
       "sqs:ChangeMessageVisibilityBatch", 
       "sqs:CreateQueue", 
       "sqs:DeleteMessage", 
       "sqs:DeleteMessageBatch", 
       "sqs:DeleteQueue", 
       "sqs:GetQueueAttributes", 
       "sqs:GetQueueUrl", 
       "sqs:ListQueues", 
       "sqs:ListDeadLetterSourceQueues", 
       "sqs:ReceiveMessage", 
       "sqs:RemovePermission", 
       "sqs:SendMessage", 
       "sqs:SendMessageBatch", 
       "sqs:SetQueueAttributes" 
       ], 
       "Resource": [ 
       { 
        "Fn::GetAtt": [ 
        "SQSFooQueue", 
        "Arn" 
        ] 
       } 
       ], 
       "Effect": "Allow" 
      } 
      ] 
     }, 
     "Roles": [ 
      { 
      "Ref": "FooRole" 
      } 
     ] 
     } 
    }, 
    "FooRole": { 
     "Type": "AWS::IAM::Role", 
     "Properties": { 
     "Path": "/", 
     "AssumeRolePolicyDocument": { 
      "Statement": [ 
      { 
       "Action": [ 
       "sts:AssumeRole" 
       ], 
       "Effect": "Allow", 
       "Principal": { 
       "Service": [ 
        "ec2.amazonaws.com" 
       ] 
       } 
      } 
      ] 
     } 
     } 
    } 
    } 
} 

Answer 1

Я постараюсь привести ваши вопросы в порядок, но сначала дайте мою общую интерпретацию этого фрагмента. Это может быть шаблон для приложения на основе AWS, которое будет запускаться под профилем экземпляра, связанного с ролью в фрагменте, и будет использовать SQS для интеграции с некоторой облачной системой в известных диапазонах IP. Предположительно, он будет обновлен для использования SDK, но, очевидно, не может получить временные учетные данные так же легко, как через конечную точку метаданных.

1. Политика очереди и ссылка на ресурс политики IAM на одну и ту же очередь, но они не являются избыточными. Один для анонимных пользователей (который не может выполнить политика IAM), а другой для экземпляров EC2.

2. Вы можете развернуть политику очереди, чтобы покрыть обе очевидные потребности, но я лично предпочитаю основные принципы IAM. Аналогично, я использовал бы устаревшие параметры управления S3, например, только если вы не можете использовать политику IAM. Но это главным образом предпочтение, за исключением случаев, когда вы должны использовать политику, связанную с ресурсами.