Support complex permissions

[iann0036]

Currently, the permissions model only supports action-based permissions with no additional scope. I propose the addition of a complex permissions set such as:

{
    "typeName": "Foo::Bar::Baz",
    ...
    "handlers": {
        "create": {
            "complexPermissions": [
                {
                    "Action": [
                        "s3:GetObject",
                        "s3:PutObject",
                        "s3:List*"
                    ],
                    "Resource": [
                        "arn:aws:s3:::limited*",
                        "arn:aws:s3:::otherlimited*"
                    ],
                    "Condition": [
                        "ForAnyValue:StringEquals": {
                            "aws:CalledVia": [
                                "dynamodb.amazonaws.com"
                            ]
                        }
                    ],
                    "Effect": "Allow"
                },
                {
                    "Action": [
                        "s3:GetObject",
                        "s3:PutObject",
                        "s3:List*"
                    ],
                    "NotResource": [
                        "arn:aws:s3:::limited*"
                    ],
                    "Effect": "Deny"
                },
                ...
            ]
        },
        ...
    }
}

Labels: enhancement

[benkehoe]

I would rather these policies be a property of the type separate from the schema. The schema says, "I perform these particular IAM actions". When registering (or especially, when sharing a registered type among accounts), you could say, "only let this type operate within this permissions boundary".

[benbridts]

I would love it if each provider used the credentials of the caller (like "native" cloudformation) and scoped it down to the Intersection of those credentials and what's in the policy. The current approach has a multiple of downsides (role for each region/resource combination, it's different than native cloudformation, if users can update a provider they could rewrite it to extract credentials and escalate their privileges)

[dchakrav-github]

I would rather these policies be a property of the type separate from the schema. The schema says, "I perform these particular IAM actions". When registering (or especially, when sharing a registered type among accounts), you could say, "only let this type operate within this permissions boundary".

+1. The intention with the handler permissions is to specify what set of permission grants it needs to operate. These are IAM actions and the permission block removes the art of guessing what they are to being easily viewable or programmatically enforceable. The admin can scope it down appropriately, via permission boundary or scope down STS/federation schemes for a given user or system. This provides clean separation of concerns between the parties involved.

[rjlohan]

I would rather these policies be a property of the type separate from the schema. The schema says, "I perform these particular IAM actions". When registering (or especially, when sharing a registered type among accounts), you could say, "only let this type operate within this permissions boundary".

For what it's worth, one of our design proposals was similar to this - and this is exactly how AWS-owned resource types behave internally, but at this time, IAM doesn't (as far as I'm aware) provide an equivalent model whereby we could intersect permissions. Either the type gets some sort of 'execution role' (e.g; as a Lambda Function does), or the caller passes a role to assume (what we do with Resource Providers currently). This is definitely something to push for in the IAM space.

[benbridts]

@rjlohan You mean where you can intersect permissions without doing an assumeRole? There is support for scoping down by adding a policy (or policy-arn) there.

[gordonmleigh]

Is there any progress on this? As far as I understand, custom resource providers that access AWS services constitute a security hole, because they can make API calls that the caller (i.e. the stack creator) doesn't have permission to make. For this reason I'd hope that Amazon would take this issue a little more seriously; especially if they have solved it for their own purposes internally (per rjlohan's comment above).