Open tgjorgoski opened 4 years ago
As a note, this can be accomplished via custom-policies.json
within your Function's directory at amplify/backend/function/<function-name>/custom-policies.json
https://docs.amplify.aws/cli/function/#access-existing-aws-resource-from-lambda-function
As a note, this can be accomplished via
custom-policies.json
within your Function's directory atamplify/backend/function/<function-name>/custom-policies.json
https://docs.amplify.aws/cli/function/#access-existing-aws-resource-from-lambda-function
The custom-policies.json file wasn't helpful in accessing the OpenSearch instance generated via the @searchable directive from a Lambda function. @josefaidt Do you have any thoughts on how this could be accomplished?
The use case I have is as follows: The auto-generated VTL for the @searchable directive is very basic and doesn't allow you to search via nested fields. There is a solution in place for this limitation, which involves implementing a custom resolver in VTL/JS. With this custom resolver, you can access the OpenSearch data source and write your own filter logic. It works, but the problem is that custom resolvers don't work with the @auth directive, and they aren't secured because every group of users from the Cognito pool can access that resolver API. I had hoped that we could simply set the @aws_iam directive on that custom resolver and access it from a Lambda function to implement our own authorization logic, but it seems impossible."
Anyone looking for a solution: https://github.com/aws-amplify/amplify-category-api/issues/1220#issuecomment-1731742414
When you create a new function (lambda) you get an option to give the lambda access to specific resources. It would be good if we can specify elasticsearch too here. (In my case I want to send a custom queries directly too, and not just through GraphQL, but it could be used to create API to allow more control of ES too, e.g. automate creating of geolocation type, update indexes etc..)