Блог

Я клонировал это решение azure-devops-on-aws и использовал dotnet lambda deploy-serverless ... для развертывания MyLizardApp в своей личной учетной записи AWS.

Во время процесса обучения я создал корзину S3 my-lizard-test , группу пользователей IAM MyLizardGroup с пользователем lizard-user и групповой политикой MyLizardApp-Policy . В политику включены эти службы:

1. Шлюз API (полный доступ, все ресурсы)
2. Облачная форма (полный доступ, все ресурсы)
3. Лямбда (полный доступ, все ресурсы)
4. S3 (полный доступ, все ресурсы)

(В конечном итоге) развертывание прошло успешно, и у меня появилось приложение Lambda, обслуживающее страницу simple razor, показывающую время.

Затем я скопировал LambdaEntryPoint.cs, aws-lambda-tools-defaults.файлы json и serverless.template в мои собственные dotnet core webapp (также проект razor) и попытался развернуть его в той же учетной записи AWS с помощью той же команды. Единственными внесенными изменениями были пространство имен LambdaEntryPoint класса (отраженное в serverless.template файле) и .csproj файл для включения:

 <AWSProjectType>Lambda</AWSProjectType>
  

и:

 <PackageReference Include="Amazon.Lambda.AspNetCoreServer" Version="5.0.0" />
  

dotnet lambda deploy-serverless ... Команда завершилась ошибкой с сообщением:

 User: arn:aws:iam::123456789120:user/lizard-user is not authorized to perform: iam:PassRole on resource: arn:aws:iam::123456789120:role/MyLizardAppServiceRole (Service: AWSLambdaInternal; Status Code: 403; Error Code: AccessDeniedException; Request ID: 12345678-1234-1234-1234-123456789012; Proxy: null)
  

Я получил команду для успешного добавления IAM службы в MyLizardApp-Policy с PassRole (все ресурсы).

Почему это было необходимо для моего личного приложения, а не для демонстрационного решения от github? Если ответ не ясен, что мне следует искать в качестве различий? Мое личное приложение незначительно отличается от демонстрационного решения, и я не думаю, что функциональные различия (в C #) будут иметь значение.

Всякий раз, когда служба AWS принимает (использует) роль IAM, служба должна иметь iam:PassRole разрешение на предоставление разрешения на использование роли. Это необходимо для предотвращения получения пользователями слишком больших разрешений.

Например, представьте обычного пользователя (не являющегося администратором), который запускает экземпляр Amazon EC2. При запуске экземпляра они могут назначить роль IAM, которая будет назначена экземпляру. Если бы этому пользователю было разрешено выбирать любую роль IAM, он мог бы выбрать роль администратора и назначить ее экземпляру EC2. Затем они могли бы войти в инстанс и использовать учетные данные для выполнения вызовов API в качестве администратора. Это нежелательное «повышение привилегий».

Аналогично, когда выполняется функция AWS Lambda, она использует роль IAM для получения разрешений. iam:PassRole Разрешение используется для управления тем, какие роли пользователь может назначить лямбда-функции.

Итак, в этом проекте есть что-то, что пытается использовать роль IAM и требует соответствующих разрешений.

Прежде всего, нам нужно знать, что такое PassRole:

iam: PassRole — это разрешение, которое определяет, какие пользователи могут делегировать роль IAM ресурсу AWS.

Как я вижу в репозитории, есть файл для CodeDeploy, в котором уже есть учетные данные, поэтому, возможно, вы используете CodeDeploy.

Но, кстати, вы используете экземпляры для развертывания лямбда-функции, и вам нужно передать роль этой лямбде, чтобы PassRole выполнял именно это

Службы AWS не могут напрямую выполнять роли, связанные с сервисом. Роль должна быть передана службе пользователем с iam::PassRole разрешением.

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

Профиль экземпляра EC2 реализован таким образом. Когда пользователь запускает экземпляр, он передает экземпляру роль, которая будет действовать как профиль экземпляра (это дополнительно необходимо iam:AddRoleToInstanceProfile для этого случая).

Другие роли, связанные с сервисом, также передаются таким образом.

Не путайте это с iam::CreateRole разрешением. Пользователь может свободно создавать роли, связанные со службой, но не может передать роль службе, когда это необходимо.

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

Что касается того, почему иногда вам нужно это разрешение, а иногда нет, то это потому, что когда вы используете пользователя root, у него будет AdministratorAccess который в основном разрешает все действия со всеми ресурсами.

Если вы создаете нового пользователя IAM или учетную запись с пустыми разрешениями, вам нужно будет добавить это разрешение вручную.