1
votes

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.

1
"AWS documents a suggested" - can you please share a link to that? - Marcin
@Marcin yep, I'll add it in with an extracted paragraph in case the docs move in the future. - John Keates
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. - Marcin
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. - Marcin
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. - Marcin

1 Answers

0
votes

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.