Suggestion: Could sidecar-deployment-user have more restricted permissions?

[danatemple]

Was just looking at the inline policy attached to the IAM user, and noted that while the S3 permissions are limited to sidecar-provisioned resources, the Lambda permissions are wide open.

Wouldn't it be a good idea to limit these to e.g. Lambda functions with the "SC-" prefix?

Not sure about what "states:" is however. I looked up "Step Function" but found none provisioned on the account.

{
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::sidecar-*",
                "arn:aws:s3:::sidecar-*\/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "lambda:*",
                "states:*"
            ],
            "Resource": "*"
        },

[aarondfrancis]

Hmm that's a good suggestion, but I'm not sure if we can do that because the prefix method could be overridden by the developer. That seems like it could be a pretty bad experience if they change the prefix of their functions and then they suddenly all 404 because they don't have the permissions.

Is that a tradeoff worth making? Do you have any thoughts on that?

[danatemple]

Well, I thought of this as I considered giving an update to a developer which would have meant them needing Sidecar to be working for them, i.e. they'd need to be able to deploy their own functions. So it is great you've thought of the SIDECAR_ENV, so they can work independently without breaking anyone else's work. I then realized however that that meant their laptop would now contain a dotenv file with the Sidecar AWS keys, so I just thought I'd check the scope. A bit worrying that anyone on a project working with Sidecar will have keys lying around that can potentially change any Lambdas in the account, i.e. our entire app - because it runs on Laravel Vapor, including production.

So I think it would be really good practice to limit the scope in some way by default - the "SC-" prefix would at least limit the scope to Sidecar, so might be a reasonable compromise.

I see the issue with the developer changing the prefix - but then maybe anyone concerned about AWS function names would also be the type that would not have a problem making the appropriate AWS policy changes to adapt?

Either way some documentation would be good:

• explain that by default, the policy is "open" - and how to edit the policy to limit it appropriately. (it's always so opaque trying to guess what scopes a given AWS operation requires!)
• make some default limitation, and explain how to adapt should you want to change the prefix.

BTW:
If you change the prefix, does it also override the "SC-" or just the name + environment part? It's not clear from the docs.
What about the "states" part of the policy - what is that used for?