An Opinionated View of AWS SAM Connectors
A newer version of AWS SAM CLI (1.59.0) was released two days ago and its change-log indicates new capabilities associated with AWS SAM Connectors.
SAM connectors are constructs designed to reduce the complexity of authoring IAM permissions that adhere to least privilege principles. The example below portrays a basic usage of SAM Connector to define a minimal integration between a Lambda function and a DynamoDB.
Pay attention to the AWS::Serverless::Connector resource with a logical ID of "WriteFunctionConnector". It requires one to define:
- A Source — Source of event (EG. API Gateway, S3, DynamoDB)
- A Destination — Often a storage (DynamoDB, S3), asynchronous invocation medium (SQS, SNS, Step Functions) or compute (Lambda)
- Permissions granted to source — AWS SAM will automatically compose the necessary access policies required for this connection to work.
SAM Veterans May Not Agree with "Simple"
As a daily user of SAM-templates for the past 3 and a half years, I personally find defining constructs worth 9 lines of code more tedious compared to using SAM policy templates that would typically require 3 lines of code for simple use-cases. SAM Connectors maybe more viable for more complex IAM definitions like Secrets Manager, Amazon Transcribe, Amazon Comprehend.
By using SAM policy templates, it only takes 3 lines of code to grant the put function the same write permission to a similar DynamoDB table defined on the previous example.
It However Reduces the Entry Barrier to Writing COMPLEX IAM Policies
I could remember starting to define my own IAM permissions using IAC tooling a couple of years ago, it was especially painful because some integrations did require me to write custom IAM roles (EG. Transcribe , Secrets manager, Comprehend) for more advance Lambda use-cases.
IMHO, SAM connectors bring value to engineering teams by reducing the level of complexity associated with creating and reading COMPLEX IAM policies.
By abstracting away the definition of "Write" and "Read" capabilities, SAM Connectors may have a huge impact on:
- Grooming serverless rookies.
- Scaling number of engineers who can write more advanced IAM policies.
- Automatic grant of newer "Read" and "Write capabilities" to your workloads.
Number of Integrations Matter
One common pitfall an engineering team could potentially encounter when using SAM connectors is abusive usage of SAM connectors. Just imagine a Lambda function that needs to access three different DynamoDB tables.
Do engineers really need to write 27 lines of code for this? I would say no and just go ahead with using SAM policy templates for simpler use-cases like providing write and read permissions to DynamoDB tables or managing s3 buckets.
Using SAM Connectors and Policy Templates Together
IMHO, SAM connectors do n ot render SAM policy templates obsolete and vice versa. SAM connectors and policy templates can be used in conjunction with each other when building more advanced SAM templates.
An example of this could be an integration with AWS services that require complex IAM definitions (Secrets Manager, Transcribe, Lex, Comprehend), DevOps service, etc.) and simple IAM definitions (DynamoDB Write, S3 Write, SQS Publish, etc.) at the same time.
Maintainability and Security
SAM abstracting the definition of "Read" and "Write" is a double-sided broadsword that one could brandish.
In the event of AWS releasing new capabilities that could get classified as "Read" permission. Upgrading your AWS SAM CLI could either harm or benefit your organization by adding new "Read" capabilities without explicit instructions from your engineering team. The same goes for "Write" permissions which often lead to unnecessary grants of data manipulation capabilities to functions that may not need every single write feature.
Abstracting away the definition of "Read" and "Write" may break the repeatability of resource definitions (Which is the whole point of Infrastructure-as-Code) if the AWS SAM team don't consider versioning the "Read" and "Write" definition in the future.
Spread in Different Sections Could be Fatal
Imagine working on large SAM projects that involve multiple CloudFormation stacks and large SAM templates (2000+ lines of code).
If engineering teams do not define how to group the SAM connector templates, SAM connectors can spread into different sections of large SAM templates.
This phenomenon could easily make maintenance a nightmare as engineers have to seek integration definitions in multiple places when trying to maintain code written by other engineers.
Conclusion
- SAM Connectors reduce the effort required in defining "complex" integrations between resources that didn't have SAM Policy Templates previously by abstracting the definition of "read" and "write" permissions to AWS resources.
- SAM Policy templates are more efficient in terms of code lines required to define simple integrations to traditional destinations like S3 buckets, DynamoDB tables, SQS queues, etc.
- SAM Connectors provide a more flexible way of specifying source and destination by offering different parameters (ARNs, IDs, Names, ETC.) compared to the limited name-based SAM Policy templates that we once had.
- SAM Connectors increased the number of code lines required to define integrations. Spreading SAM connector definitions across a template could also increase the maintainability burden of SAM templates by spreading out integration details in different sections of large SAM templates.
I'm interested to know your opinions about SAM connectors. Write you r thoughts down in the comments section. I'll love to have a discussion with you regarding SAM connectors.
References
- AWS SAM Policy templates
- AWS SAM Connector Templates
- AWS SAM Connector CloudFormation Documentation
- Prototypes for SAM Connectors
An Opinionated View of AWS SAM Connectors was originally published in Towards AWS on Medium, where people are continuing the conversation by highlighting and responding to this story.
Comments
Post a Comment