Allow developers to create AWS Lambda or SAM without granting Administrator access

Question

It seems to be impossible to allow developers to create Lambdas and create or maintain SAM Applications in AWS without essentially having AdministratorAccess policies attached to their developer's role. AWS documents a suggested IAM setup where everyone is simply Administrator, or only has IAMFullAccess, or a even more specific set of permissions containing "iam:AttachRolePolicy" which all boils down to still having enough access to grant the AdministratorAccess permission to anyone at will with just 1 API call.

Besides creating a new AWS Account for each SAM or Lambda deployment there doesn't seem to be any secure way to manage this, but I really hope I'm missing something obvious. Perhaps someone knows of a combination of tags, permission boundaries and IAM Paths that would alleviate this?

The documentation I refer to: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-permissions.html which opens with:

There are three main options for granting a user permission to manage serverless applications. Each option provides users with different levels of access control.

1. Grant administrator permissions.
2. Attach necessary AWS managed policies.
3. Grant specific AWS Identity and Access Management (IAM) permissions.

Further down, a sample application is used to specify slightly more specific permissions:

For example, the following AWS managed policies are sufficient to deploy the sample Hello World application:

• AWSCloudFormationFullAccess
• IAMFullAccess
• AWSLambda_FullAccess
• AmazonAPIGatewayAdministrator
• AmazonS3FullAccess
• AmazonEC2ContainerRegistryFullAccess

And at the end of the document an AWS IAM Policy document describes a set of permissions which is rather lengthy, but contains the mentioned "iam:AttachRolePolicy" permission with a wildcard resource for roles it may be applied on.

Strage

"AWS documents a suggested" - can you please share a link to that? – Nievesniflheim

@Nievesniflheim yep, I'll add it in with an extracted paragraph in case the docs move in the future. – Strage

I see. You either have to per-create these roles so your devs just use them, not create nor modify. If not, then you can use, as you specified, boundary policies, and this is try and see approach to find the right set for your usecase. – Nievesniflheim

Also, you could put devs in their own account as part of AWS org. Then you can use SCP policies, instead of boundary policies, to limit the account-wide permissions for them. – Nievesniflheim

In this case we did try the pre-creation method, but this doesn't work with AWS SAM and doesn't work with the Serverless Framework either since both have non-optional IAM integration. It does work if we ditch SAM and SF but that's what the developers always seem to want (because it works on their 'solo' accounts). We do have a lot of accounts (over 40) already, if every SAM or SF application would be split off we'd end up with a high multiple of that, sadly. SCPs would be a last-resort option I suppose. – Strage

I see what you mean. I think boundary and/or SCPs are top choices to consider. But I don't have any examples apart from what you can find in the docs. – Nievesniflheim

Answer 1

AWS has a PowerUserAccess managed policy which is meant for developers. It gives them access to most of the services and no access to admin activities including IAM, Organization and Account management.

• You can create an IAM Group for developers (Say Developers) and add the managed policy PowerUserAccess to the group. Add developers to this group.
• For deploying with SAM, the developers would need a few IAM permissions to create roles, tag roles. While rolling back a CloudFormation Stack, they may need a few delete permissions. While allowing the developers to create new roles for Lambda functions, you need to ensure they don't escalate privileges by using permissions boundary. A good starting point again would be to set the permissions boundary to PowerUserAccess. (until you figure out what is the right level of permissions)

Create a Policy something like this

{
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "ReadRole",
        "Effect": "Allow",
        "Action": [
            "iam:GetRole",
            "iam:GetRolePolicy",
            "iam:ListRoleTags"
        ],
        "Resource": "arn:aws:iam::ReplaceWithYourAWSAccountNumber:role/*FunctionRole*"
    },
    {
        "Sid": "TagRole",
        "Effect": "Allow",
        "Action": [
            "iam:UntagRole",
            "iam:TagRole"
        ],
        "Resource": "arn:aws:iam::ReplaceWithYourAWSAccountNumber:role/*FunctionRole*"
    },
    {
        "Sid": "WriteRole",
        "Effect": "Allow",
        "Action": [
            "iam:DeleteRole",
            "iam:DeleteRolePolicy",
            "iam:AttachRolePolicy",
            "iam:PutRolePolicy",
            "iam:PassRole",
            "iam:DetachRolePolicy"
        ],
        "Resource": "arn:aws:iam::ReplaceWithYourAWSAccountNumber:role/*FunctionRole*"
    },
    {
        "Sid": "CreateRoleWithPermissionsBoundry",
        "Effect": "Allow",
        "Action": [
            "iam:CreateRole"
        ],
        "Resource": "arn:aws:iam::ReplaceWithYourAWSAccountNumber:role/*FunctionRole*",
        "Condition": {
            "StringEquals": {
                "iam:PermissionsBoundary": "arn:aws:iam::aws:policy/PowerUserAccess"
            }
        }
    }
]
}

Note: It assumes the Lambda function names in the SAM template contains the word Function in them. (Replace the AWS Account Number in the ARNs).

• Now you can attach the above policy to the Developers IAM Group. (This would give the SAM deployment permissions to all the developers)
• Or you can create another IAM Group for SAM developers (Say SAM-Developers) and attach the above policy to the SAM-Developers group. Now add the appropriate developers (who need to deploy using SAM) to this new IAM group (SAM-Developers).
• Define the Permissions Boundary in the SAM templates as well.

Here is an example PermissionsBoundary in SAM template.

Globals:
  Function:
    Timeout: 15
    PermissionsBoundary: arn:aws:iam::aws:policy/PowerUserAccess

With that, the developers should be able to deploy using SAM provided they do not have any restrictive permission boundary.

You can set the permission boundary to AdministratorAccess for the developers or create a new Policy which combines the permissions of PowerUserAccess and the above defined policy for 'SAM' deployments. Then set this new Policy as the permission boundary for the developers.

This solution is for reference and you can build upon this. The PowerUserAccess has been set as the permissions boundary for the Lambda function roles. The PowerUserAccess is too permissive and you should further work on this to find out the right level of permission for your developers and the Lambda functions.

Sidenote: You can use this policy to allow the users to manage their own credentials.

Delisle

The problem with all permission boundaries I can come up with is that they still allow anyone to attach PowerUserAccess, AdministratorAccsss or FullIAMAccess to any role including their current role. As soon as IAM is touched it seems to be impossible to allow dynamic role creation or policy attachments without also exposing various methods of gaining administrator access. – Strage

Unless you change the above policy to say the Resource as *, the users won't be able to manipulate any other roles apart from the pattern that should contain role/*FunctionRole. Now those Roles have a permission boundary defined for them. Even given the IAMFullAccess or AdministratorAccsss, they can't go beyond the permissions boundary i.e. they can't do anything beyond a PowerUserAccess in this setup. By default, the users also can't assume those new roles. Put an Explicit Deny for those function roles to be assumed by developers – Delisle

Ensure the developers are not allowed to remove the permission boundaries from any IAM entity with an explicit Deny. Note: The permissions boundaries do not give any permission to the IAM entity, rather they are just a boundary to ensure if a user gets some permissions by mistake, still then he can't go beyond those boundaries. Think of them as a Deny and even if you have an Allow, the Deny would be the final outcome. Finally you must figure out the right permissions boundary for the devs and functions as mentioned in the answer. This is just to give an idea, how it can be done. – Delisle

I would recommend you try this out and let's know how it goes. I'm also keen to fix this policy if it allows any privilege escalation beyond a PowerUser in this case. – Delisle