pgdad
commented
3 years ago Additionally proton environment and service template creation API call IAM permissions should be such that they can be configured with 'this api call, when called, must include "cfn guard Rule Set restriction"' similar to what is possible with IAM role creation with enforced permissions boundary use as part of the IAM role creation. (iam:CreateRole has a condition key iam:PermissionsBoundary, proton should have similar for enforcement of cfn guard rule set use)
rafavallina
tatcoo
Community Note
Tell us about your request
I would like to be able to configure proton such that cloudformation guard configuration of my specification is applied to a template prior to provisioning the template. In the case where the guard discovers policy violations the template should not be provisioned and reasonable explanation (cfn guard output?) should be supplied to the user.
What do you want us to build?
There should be an optional configuration for each environment and service template of cfn guard rule set. The rule set execution/checking should be automatically performed by a lambda provided by the proton service. In cases where newer implementations of the 'lambda performing the execution' are available, it selection of such version should be configurable. Default value for such configuration should be 'latest'. (Initially the 'latest' choice could be the only, and implicit, option. We might not ever have to provide other options.).
cfn rule sets should be obtained from s3 or as part of the proton configuration (inline). This should be configurable for each environment service template, and should be versioned. Meaning that different versions, for example, of service templates, should be able to be configured with a different rule set.
Changes to the rule sets should have their own IAM permissions. (proton:PutRuleSet, with appropriate condition keys. Condition keys should allow resource tags and perhaps others).
Rule Sets should be shareable and enforceable across accounts. (Shared access to 'centrally' available s3 bucket likely suffices.)
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Larger enterprises in regulated industries would greatly benefit from 'policy as code' for their infra structure.
What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.
cfn guard is an excellent idea, no aws provided cloudformation related (cfn, cdk or service catalog) currently has an 'enforced by the service/system' way to enforce cfn guard use.
This enforcement can not, in a regulated industry, be left to a CI/CD pipeline that can be altered by developers. (there are other potential ways to solve for this requirement, for example AWS could build this kind of a facility within the cloudformation service)
Are you currently working around this issue? How are you currently solving this problem?
We are not. We primarily use Service Catalog and Terraform Sentinel policies. Service Catalog has 'limited support' for controlling what kind of resources can be provisioned via 'launch templates'. But this is not sufficient, and in particular Service Catalog has other limitations (if Service Catalog allowed cdk synth to generate template 'on the fly' it would be much more useful, but would also require/benefit from cfn guard integration) Terraform Sentinel policies, in their current implementation, are not scalable, and get really difficult to read/understand as the policies grow to fulfill enterprise needs. Additionally, Terraform is not a 'native aws' service.