Feature Request: New SAM type of AWS::Serverless::FunctionRole

[rmmeans]

Description:

SAM's ability to dynamically generate least-privilege function roles using SAM Policy templates is an extremely valuable feature. However, it presumes that the deployment pipelines that are deploying the SAM templates have the necessary IAM permissions for the pipeline itself to create IAM Roles vs passing a given role to the function.

I would like to propose a new top level type within SAM - a type that creates the same role that AWS::Serverless::Function creates when using SAM policy templates, but that is it. This would allow organizations that separate the controls around IAM management from general AWS resource management (e.g. Lambda Functions, etc) to still be able to use the power of SAM Policy Templates within a stack that only creates IAM roles.

Proposal:

---

AWS::Serverless::FunctionRole

Creates an IAM execution Role for AWS Lambda using names of AWS managed IAM policies or IAM policy documents or SAM Policy Templates that this function needs, which will be appended to the default role created by SAM for Lambda Functions.

Properties

Property Name	Type	Description
RoleName	string	The name of the Role.
Policies	string | List of string | IAM policy document object | List of IAM policy document object | List of SAM Policy Templates	Required. Names of AWS managed IAM policies or IAM policy documents or SAM Policy Templates that this function needs, which should be appended to the default role for this function.
Tracing	boolean	Indicates if this role should have access to make XRAY service calls. Enable if your Function is configured to use Tracing.

Return values

Ref

When the logical ID of this resource is provided to the Ref intrinsic function, Ref returns the resource name of the underlying IAM Role.

Fn::GetAtt

When the logical ID of this resource is specified to the Fn::GetAtt intrinsic function, it returns a value for a specified attribute of this type. This section lists the available attributes.

Attribute Name	Description
Arn	Returns the Amazon Resource Name (ARN) for the role.
RoleId	Returns the stable and unique string identifying the role. For example, AIDAJQABLZS4A3QDU576Q.

Example: AWS::Serverless::FunctionRole

Resources:
  MyLambdaFunctionRole:
    Type: AWS::Serverless::FunctionRole
    Properties:
      Policies: 
        - DynamoDBCrudPolicy:
            TableName: MyDynamoTableName
        - Version: '2012-10-17' # Policy Document
          Statement:
            - Effect: Allow
              Action:
                - s3:GetObject
                - s3:GetObjectACL
              Resource: 'arn:aws:s3:::my-bucket/*'
      Tracing: true

[brettstack]

Is it primarily Policy Templates that you're interested in exposing at a higher level?

[rmmeans]

Yes mostly. We want the full power of the Policy templates combined with lists of policy documents and lists of Managed Policies to create IAM roles for Lambda Functions. We plan on using this exactly like in my example of combining policy templates along with lists of policy documents that a given lambda function needs.

The only reason I included the Tracing property in my proposal was because the SAM currently dynamically adds the correct managed policy for XRay to the generated role if the user provides a value for the Tracing property on the AWS::Serverless::Function type.

Our end goal is such that Developers who understand SAM's syntax can request the exact same role that SAM would have created for them under a AWS::Serverless::Function, but as an first class type. This is because we have a separate process that deploys stacks creating IAM roles and the folks who have to review it.

Because no such capability exists in core CloudFormation - that means our developers and other team members must always craft the correct least privilege role for everything their function needs to use as raw CloudFormation. Having the ability to do exactly what SAM does here, but only to create the role itself would be a huge win for both the developers requesting roles as well as the folks reviewing requests for roles.

[brettstack]

I'm onboard with surfacing something like this.

Developers... can request the exact same role that SAM would have created for them under a AWS::Serverless::Function

In case it's useful to you, you can access the underlying role created for you by SAM by its logical resource ID as documented here https://github.com/awslabs/serverless-application-model/blob/master/docs/internals/generated_resources.rst#aws-serverless-function. For example, a Function with the logical resource id of MyFunction will have a role created with a logical resource id of MyFunctionRole.

[rmmeans]

With the launch of macro's, technically I could make a macro that would effectively accomplish what were after, I'm just weary of separating that from SAM itself as I really do want to create the exact same role SAM would have created for me, just as a first class type. I could easily get into a feature drift scenario where I was trying to avoid it if I created my own macro.

[brettstack]

You certainly could take that approach, but the better approach would be to submit a PR.

[rmmeans]

Thanks! I rarely work with Python, so it might be rough. Before we consider hacking a macro together, we'll at least review taking a stab at a PR now that we know a new top level type would be welcome.

[jlhood]

Yes, we're definitely open to new top-level types! I think a good first step for PR (and lower barrier to entry if you're unsure of python skills or the SAM translator internal logic), would be to submit a PR that updates the SAM spec itself and adds to the example templates showing the functionality you intend to support.

This is a much easier way to start and helps get you feedback to solidify the intended behavior before you begin implementation. You've pretty much already defined these things in the issue request above, so it should be pretty easy to translate to a PR.

[brettstack]

Agreed there should be an RFC before implementation begins. PR is one way to do that, with the biggest advantage being we have a history of the changes via commits. However, you already have the spec update and example in this Issue so we could just continue here, and I personally find it easier to edit an Issue (like I did with the Auth RFC).

I'll leave it up to you to decide (if you choose to go this route)