The ability to share Layers will be integral to their use for any organization or group of teams, or even between individuals. Adding permissions to layer versions is a process that SAM could make easier than it would be in native CloudFormation. This design proposes a new Permissions field in the AWS::Serverless::LayerVersion resource that helps create AWS::Lambda::LayerVersionPermission objects for LayerVersions.
Syntax Proposal
Pros:
Reduce developer workload
provide a convenient way to grant access permissions to layers upon layer creation
Cons:
Could quickly contribute to filling the 200 resource limit in CFN stacks.
These permissions will be expanded to one resource per permission and, if included in the globals section, be multiplied by the number of layers in a single SAM template.
This could easily balloon, but nested transforms will make this easy to manage. Just stick your layers in another template and use the LayerArns as the outputs.
Does not provide an easier way to add or remove permissions from existing layer versions
Example Template
Input yaml:
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
MyLayer:
Type: AWS::Serverless::LayerVersion
Properties:
ContentUri: ./my-layer.zip
Permissions: # list of permissions objects
-
Principal: # string or list
- arn:aws:iam::123123123123:user/James
- arn:aws:iam::123456789012:user/Brett
OrganizationId: o-eqqyngyzfx # string or list
Action: lambda:GetLayerVersion # string or list
-
Principal: # string or list
- arn:aws:iam::123456789012:user/Brett
Action: lambda:ListLayerVersions # string or list
Permissions are also a field that can be used in the AWS::Serverless::LayerVersion Globals section, setting permissions for all of the layers in a SAM template. In this example, the users specified in the globals section would be granted permissions to all the layers in the template, resulting in 4 AWS::Lambda::LayerPermission resources (2 for each layer):
Should updating the Permissions property trigger an update to the LayerVersion (even if nothing else was updated), or just update permissions?
It will always trigger a new version: doing so will avoid deleting old LayerVersionPermission objects assigned to the current version of a layer and reduce complexity and developer confusion (any update == new version).
Will SAM support managing permissions on older versions of a layer?
No. SAM will not explicitly support updating permissions on older versions of a layer. This would be best managed via the Lambda API or AWS CLI.
Will SAM support managing permissions for a range of layer versions?
No. SAM will only manage permissions on the latest version of a layer
Background
The ability to share Layers will be integral to their use for any organization or group of teams, or even between individuals. Adding permissions to layer versions is a process that SAM could make easier than it would be in native CloudFormation. This design proposes a new Permissions field in the AWS::Serverless::LayerVersion resource that helps create AWS::Lambda::LayerVersionPermission objects for LayerVersions.
Syntax Proposal
Pros:
Cons:
Example Template
Input yaml:
Output JSON:
Permissions are also a field that can be used in the AWS::Serverless::LayerVersion Globals section, setting permissions for all of the layers in a SAM template. In this example, the users specified in the globals section would be granted permissions to all the layers in the template, resulting in 4 AWS::Lambda::LayerPermission resources (2 for each layer):
FAQ
Links