More sane IAM permissions

[chainlink]

Description

Hi there, We've come up with a more restrictive set of IAM permissions (instead of allowing global access to s3, IAM, ec2 and many others which is unacceptable in many environments)

The first is an apex general policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "acm:ListCertificates",
                "acm:DescribeCertificate",
                "iam:GetRole",
                "iam:PassRole",
                "lambda:AddPermission",
                "lambda:Create*",
                "lambda:Delete*",
                "lambda:Get*",
                "lambda:InvokeFunction",
                "lambda:List*",
                "lambda:RemovePermission",
                "lambda:Update*",
                "logs:Create*",
                "logs:Describe*",
                "logs:FilterLogEvents",
                "logs:Put*",
                "logs:Test*",
                "route53:ListHostedZonesByName"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "apigateway:*",
            "Resource": "arn:aws:apigateway:*::/*"
        }
    ]
}

A TODO here is to lockdown the apigateway perms further but the risk to the account is significantly lower than global s3 and IAM and Route53 access

A secondary policy grants access to the specific function in question

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PutRolePolicy",
            "Resource": "arn:aws:iam::<AWS ACCOUNT ID>:role/<FUNCTION_NAME>-function"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:ListPolicies",
                "ssm:PutParameter",
                "ssm:DescribeParameters",
                "ssm:GetParametersByPath",
                "ssm:GetParameters",
                "ssm:GetParameter"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudformation:Create*",
                "cloudformation:Delete*",
                "cloudformation:Describe*",
                "cloudformation:ExecuteChangeSet",
                "cloudformation:Update*"
            ],
            "Resource": "arn:aws:cloudformation:<REGION>:<AWS ACCOUNT ID>:stack/<FUNCTION NAME>/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::up-<AWS ACCOUNT ID>-<REGION>"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::up-<AWS ACCOUNT ID>-<REGION>/*"
            ]
        }
    ]
}

A TODO here is to further lock down the perms on SSM and to restrict the S3 access to the specific function in question (just restricts to the up folder for now)

[tj]

Thanks! Yeah I agree it needs to be more restrictive by default, I was leaving it a bit open for future-proofing but I think feature-wise things have settled down so it's probably worth spending the time on that now

[exAspArk]

Hey, I have an issue with permissions in a Pro version only:

> up version
0.7.7-pro

> up deploy staging -v
     ...
     561ms   DEBU ensuring s3 bucket exists name=up-130059590533-us-east-1
     0s      DEBU event platform.function.update map[region:us-east-1 commit:93860a7 stage:staging]
   ⠙ 0s      DEBU event platform.deploy.complete map[commit:93860a7 stage:staging region:us-east-1 duration:1.075206171s version:]
     0s      DEBU event platform.deploy.complete map[commit:93860a7 stage:staging region:us-east-1 duration:1.075206171s version:]
   ⠙ 0s      DEBU event deploy.complete map[commit:93860a7 stage:staging duration:4.400135104s]
     Error: deploying: us-east-1: creating s3 bucket: creating bucket: AccessDenied: Access Denied
    status code: 403, request id: 86508E669CBFAD2E, host id: 6GL0SaF1hpaMtDo5+...

The up-130059590533-us-east-1 bucker already exists. With the create permission it fails with:

Error: deploying: us-east-1: creating s3 bucket: updating acceleration status: AccessDenied: Access Denied

Surprisingly, everything works without any errors with:

> up version
0.7.7

[chainlink]

As a work around to the above, we've added the following permissions (it looks like the code tries to create the bucket in all cases and then introspects the error message, but doesn't take into account access denied. This also adds permission for the transfer accelerator which is required to successfully upload the function through up.

{
            "Effect": "Allow",
            "Action": [
                "s3:CreateBucket",
                "s3:GetAccelerateConfiguration",
                "s3:PutAccelerateConfiguration"
            ],
            "Resource": [
                "arn:aws:s3:::up-<AWS ACCOUNT ID>-<REGION>"
            ]
        }

Ideally this would be changed to use the ListBucket perm to check for the existence of the bucket. Also I'm not sure why Transfer accelerator is needed in this use case?