Demystifying permissions within AWS SAM resources
The difference between IAM Policies, AWS Connectors and SAM Policy Templates.
Permission seekers and control freaks, this one is for you!
In the complex world of AWS Serverless Application Model (SAM), understanding permissions is the key to unlocking secure serverless magic. Picture this: An IAM policy, an AWS Connector and a function policy template walk into a bar… Okay, this is not the start of a bad joke, but your application will be if you don’t manage your permissions appropriately.
In this weeks post, we’ll explore the different permission mechanisms with some code examples for the visual learners amongst us. Prepare to navigate the realm of AWS SAM permissions.
IAM Policies, AWS Connectors and SAM Policy Templates
IAM Policy Statements: For the Control Freaks of Permission Management - IAM policies are for the detailed orientated system administrators and solutions architects amongst us. Oh, how they love to be in control! These fine-grained superheroes (the IAM Policies not the Systadmins) allow you to define who can access and perform specific actions within your AWS realm. With the power of IAM policies, you can micromanage permissions like a boss. It’s like assigning bouncers to protect your AWS resources and ensuring that only the chosen ones get past the velvet rope.
Inline IAM Policy within a function
Resources:
MyLambdaFunction:
Type: AWS::Serverless::Function
Properties:
Runtime: python3.8
Handler: lambda_function.handler
CodeUri: ./lambda_function
Policies:
- Statement:
- Effect: Allow
Action: s3:GetObject
Resource: arn:aws:s3:::my-bucket/*
- Effect: Allow
Action: dynamodb:PutItem
Resource: arn:aws:dynamodb:us-east-1:123456789012:table/my-table
Separate IAM Policy, attached to a function.
Resources:
MyLambdaFunction:
Type: AWS::Serverless::Function
Properties:
Runtime: python3.8
Handler: lambda_function.handler
CodeUri: ./lambda_function
Policies:
- !Ref MyLambdaFunctionPolicy
MyLambdaFunctionPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyName: MyLambdaFunctionPolicy
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Action: s3:GetObject
Resource: arn:aws:s3:::my-bucket/*
N.B. It’s also worth noting you can use AWS Managed IAM Policies and any other accepted CloudFormation mechanism here too if required.
AWS Connectors: The Predefined Dance Partners of SAM - Now, let’s meet the AWS Connectors, the happy meal of the permission world! These connectors are almost like pre-made boxes of permission happiness where you pick your main, your side and your toy!
They come with predefined permissions, like ready-made menu options, making integration a breeze. Fancy your cheeseburger with a side of Amazon S3? The S3 Connector has got you covered. Want to savour the flavours of DynamoDB? The DynamoDB Connector will satisfy those cravings. They simplify integration and package it into fewer lines than an AWS IAM Policy.
Serverless Function using Connector
Resources:
MyLambdaFunction:
Type: AWS::Serverless::Function
Properties:
Runtime: python3.8
Handler: lambda_function.handler
CodeUri: ./lambda_function
Events:
MyS3Event:
Type: S3
Properties:
Bucket: 'my-bucket'
Events: s3:ObjectCreated:*
Connectors:
S3BucketConnector:
Properties:
Destination:
Id: 'my-bucket'
Permissions:
- Read
SAM Policy Templates: Function-Specific Permission Ninjas - Enter the SAM Policy Template, the stealthy ninjas of permissions. With these policies, you can grant specific permissions to your Lambda functions without breaking a sweat. It’s like having a team of specialised martial arts experts guarding each function. Whether you define policies inline or reference existing IAM policies, these ninjas ensure your functions have the right permissions, without causing unnecessary chaos. Talk about precision and elegance! To top this off, it’s much shorter than writing a whole IAM Policy statement.
Serverless Function using Connector
Resources:
MyLambdaFunction:
Type: AWS::Serverless::Function
Properties:
Runtime: python3.8
Handler: lambda_function.handler
CodeUri: ./lambda_function
Policies:
- DynamoDBReadWritePolicy:
TableName: my-table
Differences and Use Cases: SAM Permissions in Action
In a nutshell, here’s a breakdown of the differences and use cases for IAM Policies, AWS Connectors, and SAM Policy Templates:
-
IAM Policies: Offer fine-grained control over permissions at the user or role level. Ideal for managing access to multiple AWS resources or services with precision.
-
AWS Connectors: Simplify integration with specific AWS services by providing predefined permissions out of the box. Perfect for streamlined integration without the need for manual IAM policy configuration.
-
SAM Policy Templates: Grant function-specific permissions within your SAM template, eliminating the need for separate IAM policies. Well-suited for managing permissions at the function level with a focus on individual functions.
Choose IAM Policies for granular control, AWS Connectors for simplified service integration, and SAM Policy Templates for function-specific permissions. Tailor your approach based on your specific requirements, balancing control and convenience.
In closing…
And that concludes today’s lecture, permission aficionados! We’ve mastered the art of AWS SAM permissions together. IAM Policies, AWS Connectors, and SAM Policy Templates are your permission pals, each with its unique style. IAM policies provide control, Connectors are the happy meal of the permission world, and function policies bring stealthy precision. Embrace the right approach for your use cases and security needs, ensuring your serverless applications operate through the AWS SAM world with style.
Stay tuned for more AWS SAM adventures.
Sources
https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-permissions.html