Concern over permissions needed

[reidca]

I have this working now and am really pleased with the ability to do adhoc code from within cloudformation. It will really help when cfn does not support something natively which is very often.

I have deployed the function using a stackset across multiple accounts and I export the Arn of the function then import it as the ServiceToken for the custom resource.

My only concern is that in order to be useful this needs to be a generic function that can be used across the account and therefore effectively requires administrator permissions.

The only alternative I can think of is to deploy a specific version of the function and accompanying execution role that has only the permissions needed with every stack which is not ideal.

What are your thoughts on this?

[dejonghe]

Yeah, I see what you mean. I would not advise giving this function full admin privileges. If you're going to deploy it across multiple accounts for general use, I would give it permissions on a case by case basis. I would hope that this function only gets used for the edge cases that CFN doesnt cover. For instance start out with just "iam:UpdateRole", when you find another use for it add that to your StackSet IAM policy for the function. What are your thoughts?

[reidca]

Unfortunately those 'edge cases' are found quite often! I have lost count of the times that cfn doesn't support something I need recently hence my delight when I saw this code.

But I tend to agree that the admin permissions are too scary unless of course the execution of the Lambda itself is restricted to a role that only admin users can assume.

If this is possible then you are not really changing anything. The lambda function is just an extension of the admin role.

There is no Lambda function policy associated with the function granting the "invokefunction' permission therefore it seems that the permission to invoke it is based on the role of the person creating or updating the stack which in my case is an admin role. To be certain I guess you could add a deny permission to explicitly disallow invoke by anyone other than the admin role.

[dejonghe]

But I tend to agree that the admin permissions are too scary unless of course the execution of the Lambda itself is restricted to a role that only admin users can assume.

I don't think this is the case. Because, you built the role lambda uses with an admin account lambda is ok to assume that role, the user is simply invoking it. As you mentioned you could limit who's allowed to invoke it.

The other route would be to just have everyone that's using it build their own copy of the lambda with the specific permissions it needs for the given stack/nested stack but i can see your point on how that might get repetitive.

I don't have time to look into it today but I recall seeing something that might help. Look into IAM PassRole permission to see if that would solve our need.