An Opinionated View of AWS SAM Connectors
A newer version of AWS SAM CLI (1.59.0) was released two days ago. Its changelog indicates new capabilities associated with AWS SAM Connectors.
SAM connectors are constructs designed to reduce the complexity of authoring IAM permissions that adhere to the least privilege principles.
The example below portrays the most simple usage of a SAM Connector. It represents a classic definition of a common “Write” integration between a Lambda function and a DynamoDB.
Pay attention to the AWS::Serverless::Connector resource with a logical ID of “WriteFunctionConnector”. In order to define SAM Connectors one must define a resource with the following portions:
- A Source — Source of event (EG. API Gateway, S3, DynamoDB)
- A Destination — Often a storage (DynamoDB, S3), asynchronous invocation medium (SQS, SNS, Event Bridge) or compute (Lambda, Step Functions)
- 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.
By using SAM policy templates, it only takes 2 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. Secrets manager) 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 encounter when using SAM connectors is the abusive usage of this new construct. Just imagine a Lambda function that needs access to 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 not 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), DevOps services (Code Commit, Code Build, Code Deploy, 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 reduces 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 your thoughts down in the comments section. I’ll love to have a discussion with you regarding SAM connectors.
