serverless-application-model: AWS_IAM auth does not allow InvokeRole override
Description:
When using the new AWS_IAM auth type, the InvokeRole is always set to CALLER_CREDENTIALS even when I specify an override. The problem here is that, it forces the caller to have both API Gateway’s invoke permission as well as lambda:InvokeFunction permission. This breaks the API abstraction and leaks implementation details (that there’s a Lambda behind API Gateway, and the name of the function).
Steps to reproduce the issue:
- create API with auth type set to
AWS_IAMand setInvokeRoletonull
Observed result:
API endpoints still uses CALLER_CREDENTIALS
Expected result:
Execution roleto be `nullInvoke with caller credentialsto bedisabled
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 13
- Comments: 22 (12 by maintainers)
@ashier @caspian154 this is now released, you can now set
InvokeRole: NONE.Had a conversation with @benkehoe today where he reiterated his above comment (https://github.com/awslabs/serverless-application-model/issues/923#issuecomment-496630437) that we could update the default behavior in a backwards-compatible way by adding a AWS_IAM_v2 authorizer. Commenting to make sure we discuss this at our next PR/Issue review meeting.
@ashier We’re working on making our release process more transparent to external customers, but we’re not quite where we want to be yet. For now, you can see when we cut release branches, which can give you some indication of when we begin working on a specific release.
I don’t know of a workaround to this issue, unfortunately.
Would there be a timeline when are we expecting the 1.14.0 version? Or are there any workarounds (without manually unchecking the box) that we can do while we wait for this to be released?
It makes the desired behavior possible, sure. But it’s also setting us up for a lot of new users asking about IAM errors they don’t understand and getting told to use this trick, and then copy-and-pasting that for the rest of their days without understanding it. This goes against the mission of SAM, which is to make CloudFormation simpler and more understandable, with better defaults.
If I’m missing something, if there’s a reason users should want to use caller credentials from API GW to Lambda by default, or why we should guide them in that direction with this default, I’m all ears.
Is the plan to change the default to not use caller credentials? I am in favor of such a plan. Using caller credentials isn’t the default in API Gateway, so I would consider it unexpected behavior for SAM to change that.
@jadhavmanoj that’s correct.
That’s a good question. @brettstack might know, otherwise I’ll investigate more and see what SAM should do in this case.