-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run terraform-compliance for only new (create) resources, via an additional -new CLI filter ? #408
Comments
additionally, there are certain tests we would want to run on resources that are labeled as We love the tool but it is hard to deploy to prevent, when many of the same compliance violations already exist |
Hi @mdesmarest, This's an excellent feature request! I have built a preliminary solution on #447. I'm sorry this took months to look into :) |
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>
.
|
@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 |
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. |
@mdesmarest just released |
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>
.
|
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
vsupdate
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 asupdate
for say a tag, but then fail a feature because we are trying to advise users tocreate 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:
The text was updated successfully, but these errors were encountered: