Closed wbingli closed 4 years ago
This is one-way door decision, we can't add this constraint back in later without it being a breaking change. So I'd like to make sure we have a use-case for it. We don't quite have external credentials nailed down. It's likely handlers like this would require e.g. SSM permissions. Non-provisionable resources won't have handler definitions. Do we have a use-case right now for this?
One of the use case is newrelic alert, their handlers actually don't need AWS IAM permissions, and they have to workaround the permission constraint to have some fake permissions such as alert:CreateAlert
.
How to manage external credential may depend on how customer implement their handlers. One of solutions I see is they require an app key as resource parameter. CloudFormation could support inject SSM parameter into those resource parameter, but it becomes resource consumer grant permissions to the stack not resource handlers.
This is one-way door decision, we can't add this constraint back in later without it being a breaking change. So I'd like to make sure we have a use-case for it. We don't quite have external credentials nailed down. It's likely handlers like this would require e.g. SSM permissions. Non-provisionable resources won't have handler definitions. Do we have a use-case right now for this?
One of the use case is newrelic alert, their handlers actually don't need AWS IAM permissions, and they have to workaround the permission constraint to have some fake permissions such as
alert:CreateAlert
.How to manage external credential may depend on how customer implement their handlers. One of solutions I see is they require an app key as resource parameter. CloudFormation could support inject SSM parameter into those resource parameter, but it becomes resource consumer grant permissions to the stack not resource handlers.
I think we can add this as an interface bump. If permissions are optional for now, we will be able to version the interface to make them mandatory, and block new MPR registrations that don't include permissions at that point. It won't impact existing registered types. The control probably only needs to apply to public types as well. Permissions is hard to require from 3P types since they may not need them.
Issue #, if available: N/A
Description of changes: This PR will allow empty permissions of handler. In the discussion in PR(https://github.com/aws-cloudformation/aws-cloudformation-rpdk-java-plugin/pull/161). In some cases(e.g. external customer doesn't use any AWS resources), handlers don't need any AWS permissions. In such way, we should allow an empty permissions.
Still keep the
permissions
as required so it should explicitly declare all permissions even it's empty.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.