Run terraform-compliance for only new (create) resources, via an additional -new CLI filter ?

[mdesmarest]

Feature Request

The ability to flag within the resource_changes block for resources, the same way we can interact with specific values for address, module address ,etc in the actual resource block. The ability to conditionally flag on create vs update allows for flagging on new infrastructure being created to be flagged for non use of a module, while ignoring updates to existing resources that were created previous to a module's creation or use.

We are in the midst of standardizing our configurations and directing our devs to use modules, since these will help enforce the same best practices we are flagging for in features. For a Feature or Scenario to flag on Given this, When this, Then that we can't flag on existing resources that may come into the plan as update for say a tag, but then fail a feature because we are trying to advise users to create all s3 resources using our module since using the module on already created resources is not feasible due to state files already mapping resources.

we also can't restrict s3 resources by saying Given aws_s3_bucket defined, Then the scenario should fail use the module please.

This is a feature in hashicorp Sentinel and we were advised that this is a must have if we are to flag for module use while not flagging infrastructure created pre module

We need a way to account for the Terraform json block for resource_changes below to screen for what is being created vs updated.

Block below:

"resource_changes":[
{},
{},
{},
{
"address":"aws_s3_bucket.missing_Server_side_encryption_apply_sever_side",
"mode":"managed",
"type":"aws_s3_bucket",
"name":"missing_Server_side_encryption_apply_sever_side",
"provider_name":"aws",
"change":{
"actions":[
"create"
],
"before":null,
"after":{},
"after_unknown":{}
}
},
{
"address":"aws_s3_bucket.pagerduty_s3",
"mode":"managed",
"type":"aws_s3_bucket",
"name":"pagerduty_s3",
"provider_name":"aws",
"change":{
"actions":[
"update"
],

[mdesmarest]

additionally, there are certain tests we would want to run on resources that are labeled as create since those can be fixed within the terraform code itself and then replanned to pass for deployment, also run certain features/scenarios on update and ignore resources that are in the state but not seeing new changes. The flexibility to run only on create lets us fix 100% of the compliance issues we are looking for. many of our features would not apply to resources that are update since flagging and resolving via plan/apply is problematic. Essentially we are looking to "stop the bleeding" and prevent new non compliant configurations, while we address the existing infrastructure in a safe manner. Many times this will be outside of terraform and will be adjusted via CLI/console, for import to state later.

We love the tool but it is hard to deploy to prevent, when many of the same compliance violations already exist

[Kudbettin]

Hi @mdesmarest,

This's an excellent feature request! I have built a preliminary solution on #447.
What do you think about it? Does that help with issues on integrating terraform-compliance?

I'm sorry this took months to look into :)

[mdesmarest]

Not a problem at all, happy to take a look and give some feedback! I have alot of test cases ready to go. Thanks for starting the lift!

…

On Fri, Jan 15, 2021, 12:50 PM Kaan Katırcıoğlu ***@***.***> wrote: Hi @mdesmarest <https://github.com/mdesmarest>, This's an excellent feature request! I have built a preliminary solution on #447 <#447>. What do you think about it? Does that help with issues on integrating terraform-compliance? I'm sorry this took months to look into :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#408 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AINEMD3BUM5DTVGYR5LKFGDS2B6AHANCNFSM4TP64NSA> .

[mdesmarest]

@Kudbettin Thanks so much!!! This looks exactly like what we were looking for as well as opening up the metadata to a lot more filters and flags.

I can't wait to spin this up and try it out! Looking forward to the merge 🤞

Looking through the code this will be very helpful on our Atlantis PR scans for the reasons below, as well as open us up to create our state based compliance engine for long term cleanup of compliance failures on already existing resources

1.Filter tuned features that apply to full fixes for create action
2.Create secondary features to flag on same resource type but only for update that do not cause resource destruction
3.Tune down noise on resources that are no-op since on PR it creates difficulty having a feature flag on a resource that was not changed, and inhibits protected branch enforcement.
4. This also now allows us to enforce module use, since moving forward we are enforcing modules on certain resource types and need to account for resources created before the inception of the module while also preventing new resources to be created without the module.

[Kudbettin]

Awesome! Glad this’s useful.

It seems you will have a number of interesting and creative use cases of terraform-compliance. If you would like to share any of those with the community, we recently released this repository to document some use cases.

As always, feel absolutely free to open issues if something comes up.

[eerkunt]

@mdesmarest just released 1.3.12 :)

[mdesmarest]

I can't wait to try this and build into my existing features and test in my Atlantis workflow. What a journey this has been. All other scanners left us frustrated and wanting what common sense should be available, as well as trying very hard not to go with Sentinel for both cost and flexibility. When we came upon your tool we saw alot of possibility and several gaps, but nothing out of the realm of possibility. This really is the premiere tool for terraform compliance checking. Hats off to you both and the other tireless folks who contribute to this tool. Thank you for :

…

-Enhanced silent mode to allow us customize output parsing on failures. -the ability to test for both misconfiguration and the absence of arguments in terraform plans. (from watching all the traffic in late December, it seems the `known after apply` incorrectly populating the stash opened a furry of fixes and headaches) Looks like it lead to far more solid parsing though!

-metadata filtering outside the values block to more deeply account for "terraform magic" Amazing work from a small team of passionate developers. Looking forward to pushing the limits with this and seeing where this can go next!

On Mon, Jan 18, 2021, 5:52 AM Emre Erkunt ***@***.***> wrote: @mdesmarest <https://github.com/mdesmarest> just released 1.3.12 :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#408 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AINEMD2SYPN3BKWC6WE257DS2QHFTANCNFSM4TP64NSA> .