AWS SAM serverless connectors

Yesterday, AWS announced a new feature for AWS SAM called Serverless Connectors. I was particularly excited about this one for two reasons.

Firstly - I often see tutorials gloss over the implementation of the principle of least privilege when it comes to identity and access management (IAM). SAM Serverless Connectors seeks to correct this by making it easy to create AWS::IAM::ManagedPolicy resources just by defining a source resource, destination resource, and type/s of permission (e.g. Read or Write).

Secondly - in a meeting I had recently with the Serverless product team at AWS via the Community Builders programme, I heard that a feature to solve this problem was on the way. I was expecting that it might be something announced at re:Invent, so to receive it this early was a pleasant surprise.

All of the source code that makes up the example application detailed in this article is available on GitHub in the aws-sam-serverless-connector-demo repository.

Getting started

It’s worth pointing out at this stage that in order to make use of any features of AWS SAM, the serverless transform needs to be added to the top level of the CloudFormation template. This instructs the CloudFormation service to convert the conceptual AWS::Serverless::* resources to the underlying CloudFormation resources.

1
Transform: AWS::Serverless-2016-10-31

In this article we’ll look at three examples where a IAM managed policy is generated to grant access to a particular resource, scoped down to Read or Write privileges. The way that the AWS::Serverless::Connector resource works is that a Source needs to be specified. We’ll be using a Lambda function as the source. Normally when writing an IAM policy a source wouldn’t need to be specified, so this may feel a little strange. The reason for specifying the Source is that it allows SAM to be smart and automatically attach the AWS::IAM::ManagedPolicy that is created to the role that is created for the Lambda function. Winner!

When the Lambda function is defined, nothing out of the ordinary needs to be specified.

1
ExampleFunction:
2
  Type: AWS::Serverless::Function
3
  Properties:
4
    Timeout: 3
5
    CodeUri: hello_world/
6
    Handler: app.lambda_handler
7
    Runtime: python3.9
8
    Architectures:
9
      - x86_64

Step Functions State Machine

The first example we’ll explore is if a Lambda function needs to interact with a Step Functions State Machine. The State Machine itself is defined as usual. The below snippet shows a sample AWS::Serverless::StateMachine resource. The policies and definition are for example only, they are not relevant to the function of the Serverless Connectors released yesterday.

1
ExampleStateMachine:
2
  Type: AWS::Serverless::StateMachine
3
  Properties:
4
    Policies:
5
      - Version: "2012-10-17"
6
        Statement:
7
          - Effect: Allow
8
            Action:
9
              - s3:ListBucket
10
            Resource: "*"
11
    Definition:
12
      StartAt: Succeed
13
      States:
14
        Succeed:
15
          Type: Succeed

Now we get to the good stuff. To create an IAM managed policy to allow Write access to the resource represented by the ExampleStateMachine logical ID. By specifying ExampleFunction as the source, the created policy will be attached to the Lambda function execution role. It is worth mentioning at this stage that Source and Destination don’t just support the referencing another resource in the stack via a logical ID in the Id key. Support for keys such as Arn is also there to cover off those cases where a you may want to connect resources that aren’t necessarily in the same stack.

1
FunctionToStateMachineConnector:
2
  Type: AWS::Serverless::Connector
3
  Properties:
4
    Source:
5
      Id: ExampleFunction
6
    Destination:
7
      Id: ExampleStateMachine
8
    Permissions:
9
      - Write

When the stack has been created, it’s possible to see the policy created in the IAM console. I must say that when I heard about this feature, I was a little worried that it might be provision overly-permissive policies. I really like the fact that Read and Write focuses on application level permissions rather than infrastructure. For example, the Write permissions connecting to a state machine could have granted permissions to edit or even delete the resource. I’d say the product team have pretty much hit the nail on the head here.

1
Version: "2012-10-17"
2
Statement:
3
  - Action:
4
      - states:StartExecution
5
      - states:StartSyncExecution
6
    Resource:
7
      - arn:aws:states:eu-west-1:012345678901:stateMachine:ExampleStateMachine-WnEDETcG2BGX
8
    Effect: Allow
9
  - Action:
10
      - states:StopExecution
11
    Resource:
12
      - arn:aws:states:eu-west-1:012345678901:execution:ExampleStateMachine-WnEDETcG2BGX:*
13
    Effect: Allow

DynamoDB Table

The next example to look at is generating permissions for Write permissions on a DynamoDB.

1
ExampleTable:
2
  Type: AWS::Serverless::SimpleTable
3
  Properties:
4
    PrimaryKey:
5
      Name: Id
6
      Type: String
7

8
FunctionToTableConnector:
9
  Type: AWS::Serverless::Connector
10
  Properties:
11
    Source:
12
      Id: ExampleFunction
13
    Destination:
14
      Id: ExampleTable
15
    Permissions:
16
      - Write

In the code snippet below is the IAM managed policy that’s generated for Write permissions on a DynamoDB table.

1
Version: "2012-10-17"
2
Statement:
3
  - Action:
4
      - dynamodb:PutItem
5
      - dynamodb:UpdateItem
6
      - dynamodb:DeleteItem
7
      - dynamodb:BatchWriteItem
8
      - dynamodb:PartiQLDelete
9
      - dynamodb:PartiQLInsert
10
      - dynamodb:PartiQLUpdate
11
    Resource:
12
      - arn:aws:dynamodb:eu-west-1:012345678901:table/serverless-connector-resource-demo-ExampleTable-G4C7DC159EJL
13
      - arn:aws:dynamodb:eu-west-1:012345678901:table/serverless-connector-resource-demo-ExampleTable-G4C7DC159EJL/index/*
14
    Effect: Allow

S3 Bucket

The final example shows how to grant Read permissions on an S3 bucket from the Lambda function we created earlier.

1
ExampleBucket:
2
  Type: AWS::S3::Bucket
3

4
FunctionToBucketConnector:
5
  Type: AWS::Serverless::Connector
6
  Properties:
7
    Source:
8
      Id: ExampleFunction
9
    Destination:
10
      Id: ExampleBucket
11
    Permissions:
12
      - Read

Contained in the final code snippet is the IAM managed policy that’s generated for Read permissions on a S3 bucket.

1
Version: "2012-10-17"
2
Statement:
3
  - Action:
4
      - s3:GetObject
5
      - s3:GetObjectAcl
6
      - s3:GetObjectLegalHold
7
      - s3:GetObjectRetention
8
      - s3:GetObjectTorrent
9
      - s3:GetObjectVersion
10
      - s3:GetObjectVersionAcl
11
      - s3:GetObjectVersionForReplication
12
      - s3:GetObjectVersionTorrent
13
      - s3:ListBucket
14
      - s3:ListBucketMultipartUploads
15
      - s3:ListBucketVersions
16
      - s3:ListMultipartUploadParts
17
    Resource:
18
      - arn:aws:s3:::serverless-connector-resource-demo-examplebucket-97ah5qo379y1
19
      - arn:aws:s3:::serverless-connector-resource-demo-examplebucket-97ah5qo379y1/*
20
    Effect: Allow

Rounding up

Useful links

Summary

In summary, I’m really pleased by this new release. I believe it’ll make it easier for people to learn and get started with building on AWS without creating drastically over permissive IAM policies.

Alex Kearns