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 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::RestApiCloudFormation resources - iteratively remove any
credentialsfields fromAWS_PROXYintegrations
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!
The post AWS SAM + Cloudformation macros, a patch made in heaven appeared first on theburningmonk.com.
Top comments (0)