Yan Cui
I help clients go faster for less using serverless technologies.
This article is brought to you by
I never fully recovered my workspace setup when I upgraded my laptop two years ago, and I still miss things today. If only I had known about Gitpod back then…
Over the last few weeks I have been working with a very ambitious client – Solve, who is building a new murder mystery game. They are doing some really cool things technically, and are building an entirely serverless stack.
While working with Solve I have spent a lot of time with AWS SAM. That experience also helped inform my opinion about SAM, as I explained in this article. Where compared with the Serverless framework it’s lacking the customizability that the serverless framework offers through its plugin system.
With the Serverless framework, I can write plugins to tailor the framework’s built-in behaviours. This gets me out of jail whenever I disagree with the framework’s choices. However, I don’t have such a luxury with SAM.
Just today, I ran into a problem with SAM’s support for AWS_IAM authorizer in API Gateway. The built-in behaviour is such that, anytime I choose to use AWS_IAM as the authorizer it’ll default the InvokeRole
to CALLER_CREDENTIALS
. Even if I explicitly set InvokeRole
to null
.
This means the caller’s IAM role would be used to invoke the Lambda function. So, to call my IAM-protected endpoint, I need to sign the request with an IAM profile with the permissions to:
- execute-api:Invoke against the API Gateway resource
- and lambda:InvokeFunction against the Lambda function sitting behind API Gateway
That completely breaks the abstraction layer! As a caller, I not only need to know the endpoint I wish to talk to, but also how it’s implemented under the hood. If the API maintainer renames the functions behind the endpoint, my code would suddenly break.
If this issue also impacts you, then keep an eye on this Github issue.
Since SAM doesn’t have a plugin system, I would have to wait for the SAM team to fix the problem.
Or, do I?
Since SAM is ultimately just CloudFormation with a magical macro called AWS::Serverless-2016–10–31
. I can modify the CloudFormation template it transformed with my own macros.
In this case, we were able to get ourselves out of jail by writing a CloudFormation macro to:
- look for
AWS::ApiGateway::RestApi
CloudFormation resources - iteratively remove any
credentials
fields fromAWS_PROXY
integrations
With this macro, we were able to unblock ourselves.
Admittedly, using CloudFormation macros is a rather heavy-handed approach to customize SAM’s behaviour! However, in the absence of a built-in mechanism for customizing SAM, it was the best bad idea we were able to come up with. Please let us know in the comments if you know of a simpler, more elegant solution!
p.s. Solve is looking for a backend engineer to join their team in Shoreditch, London. If you’re looking for an opportunity to work with serverless technologies and build games for millions of users, then you should consider applying!
Whenever you’re ready, here are 3 ways I can help you:
- Production-Ready Serverless: Join 20+ AWS Heroes & Community Builders and 1000+ other students in levelling up your serverless game. This is your one-stop shop for quickly levelling up your serverless skills.
- I help clients launch product ideas, improve their development processes and upskill their teams. If you’d like to work together, then let’s get in touch.
- Join my community on Discord, ask questions, and join the discussion on all things AWS and Serverless.