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

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

0 голосов
/ 02 мая 2018

Я хотел бы создать собственную политику, обеспечивающую детальный доступ к таблицам 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, например, такой оператор, как {Эффект: «Разрешить», Действие: «DynamodB: », «Ресурс»: «»}

Мой обработчик 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?

1 Ответ

0 голосов
/ 02 мая 2018

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

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

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

...