Как я могу использовать разрешения, сгенерированные в AWS Custom Authorizer, в своем лямбда-коде?

Question

Я хотел бы создать собственную политику, которая обеспечивает детальный доступ к таблицам DynamoDB в пользовательском авторизаторе AWS. Это возможно?

В безсерверном режиме моя конфигурация выглядит так:

functions:
  APIAuthorizer:
    handler: src/services/auth/handlers.apiAuthorizer
    cors: true
  GraphQLAPI:
    handler: src/services/graphql/handlers.apiHandler
    events:
      - http:
          path: "/api"
          method: post
          cors: true
          authorizer:
            name: APIAuthorizer
            type: request
            resultTtlInSeconds: 0

Я убедился, что вызывается мой пользовательский авторизатор и что он генерирует различные разрешения (sts:AssumeRole, lambda:InvokeFunction, execute-api:Invokeи другие) необходимы для успешного вызова обработчика API. Так что мой пользовательский авторизатор работает, и результат, который он обеспечивает, необходим.

Однако, когда авторизатор включает в себя разрешения Dynamodb, например, такой оператор, как { Effect: "Allow", Action: "Dynamodb:", "Resource": ""}

мой обработчик API (функция GraphQLAPI) завершается с таким сообщением, как

User: arn:aws:sts::<myaccountid>:assumed-role/<mydefaultrole>/myservice-mystage-GraphQLAPI is not authorized to perform: dynamodb:Query on resource: arn:aws:dynamodb:us-east-1:<myaccountId>:table/<mytable>/index/<someIndex> 

(Я заметил, что жалоба касается разрешения для индекса, поэтому также попытался добавить определенные разрешения для этого индекса и / или для всех индексов, но это не имеет никакого эффекта.)

Суть в том, что после многих различных попыток, разрешения динамодаба, выданные пользовательским авторизатором, полностью игнорируются. Мой код lambda node.js использует SDK узла AWS, который должен получать разрешения из среды экземпляра. Я предполагал, что это будет включать разрешения, сгенерированные пользовательским авторизатором.

Наконец, я заметил, что в документации AWS javascript SDK о том, как загружаются учетные данные, говорится только "Роль выполнения предоставляет функции Lambda учетные данные, необходимые для запуска и вызова других веб-служб". То есть в нем не упоминаются динамически сгенерированные учетные данные, выданные пользовательским авторизатором.

Это, кажется, объясняет поведение, которое я вижу. Мой обработчик API имеет разрешения только от статически определенной роли выполнения (сообщение об ошибке также указывает на это), и ему не предоставляются разрешения, созданные пользовательским авторизатором.

Есть ли возможность использовать разрешения, которые мой пользовательский авторизатор генерирует внутри моего обработчика API?

Answer 1

Я думаю, что вы неправильно поняли вывод политики IAM от Lambda авторизаторов. Цель вывода политики IAM от авторизатора состоит в том, чтобы отразить, каким должен быть результат для шлюза API в отношении продолжения обработки запроса.

Возвращенная политика не обязательно применяется к вызываемой функции, но применяется к вызову функции. Он просто сообщает API-шлюзу, к каким API запрашивающий пользователь имеет доступ.

Если вы хотите дать вызываемым функциям API определенный доступ к ресурсам, таким как таблицы DynamoDB или любые другие ресурсы AWS, их необходимо настроить в роли, назначенной функции Lambda. В противном случае вы сможете указать роль, которую будет вызывать лямбда-функция, которая предоставит ей дополнительные разрешения. Эта роль может быть передана через параметры контекста от авторизатора.