[BUG] eval_conflict_error: object keys must be unique when evaluating terraform plan file

[james1miller93]

Describe the bug
We're hitting the eval_conflict_error: object keys must be unique error when evaluating a large terraform plan file.

FATAL lib/fugue/resource_view/terraform.rego:120: eval_conflict_error: object keys must be unique

This is a legacy project which we're migrating to a new process which includes regula policy evaluation. The projects state already contains a large number of resources and nested modules.

It looks like a bug in the module parser here is causing the error.

We're running the regula library and policies via conftest, but I've also reproduced the error when running the config through the regula binary.

I've also tested this with a plan generated by multiple versions of terraform (including latest) and the behaviour is the same.

How you're running Regula
Please include versions of all relevant tools. Some examples:

• Using Regula v2.1.0 as a Rego library with Conftest v0.23.0 and a Terraform plan JSON input that I generated with Terraform v1.0.11 - this just hangs when run locally. This is how we run regula in our pipelines and the error has been produced in this environment.

terraform plan -out=terraform.tfplan --lock=false
terraform show -json terraform.tfplan > plan.json
conftest pull --policy ./policy "github.com/fugue/regula//rego/conftest?ref=v2.1.0"
conftest pull --policy ./policy/regula/lib "github.com/fugue/regula//rego/lib?ref=v2.1.0"
conftest pull --policy ./policy/regula/rules "github.com/fugue/regula//rego/rules?ref=v2.1.0"
conftest test ./policy plan.json

• Using Regula v2.1.0 as a CLI tool and a Terraform plan json file as an input.

regula run plan.json --verbose

Operating System
macOS Monterey 12.0.1
x86_64

IaC Configuration
Unfortunately, I cannot share the full terraform configuration. However, I may be able to share the output of terraform state list if required.

Additional context
The state in this project does contain over 1500 resources, so the plan file we're evaluating is large.

[jaspervdj-luminal]

@james1miller93 Thanks for the detailed info! I had a quick try at reproducing this but haven't had luck so far.

We'll keep investigating, in the meantime, these are two things that could be helpful to us to narrow this down further:

1. Does this issue also occur when you run the regula binary against the .tf files directly (rather than the plan)? We've made some improvements to this lately, and it could be a temporary workaround (though I understand it wouldn't fit into your workflow easily).

2. The following command should print a highly redacted overview of just the module hierarchy (where I also suspect the bug is). If this does not contain any sensitive details, would it be possible to post this here or send it to [email protected]? Feel free to censor out any further details if necessary:

jq '.configuration.root_module | del(.outputs) | del(.resources) | walk(if type == "object" and .module.resources then del(.module.resources) | del(.module.outputs) | del(.expressions) | del(.module.variables) | del(.source) else . end)' <plan.json

[james1miller93]

@jaspervdj-luminal - Thanks for the pointers and for looking into this for me.

1. Running the regula binary directly against the .tf files does work. As mentioned above, this doesn't fit into our current workflow, but does give us something to work with in the meantime.

2. I've sent the redacted output to you via email. I've redacted a few additional pieces of data in the file, but the module/object names remain untouched and I've made it clear where the redacted info is missing.

Let me know if you need any further details, or if you need me to run any additional tests.

[james1miller93]

@jaspervdj-luminal - Have you had a chance to look into this issue?

[jaspervdj-luminal]

@james1miller93 Apologies, priorities got shuffled around a bit and then the holidays hit. I will be looking into this today.

[jaspervdj-luminal]

@james1miller93 I think I was able to reproduce the issue using the redacted plan. Thanks a lot for providing that! If this is at all possible, could you give the fix/RM-6363/module-ambiguity branch a try? I believe it could fix the issue.

[james1miller93]

@jaspervdj-luminal - Thank you for working on this.

The issue appears to be fixed in the branch you've created.

Do you have any idea when this will be published in an official release?

[jaspervdj-luminal]

@james1miller93 I'll add a test and get this merged into master, that way it should be in the release next Thursday.

[jaspervdj-luminal]

We've found an issue in master and will have to delay the release until Monday, my apologies.

[mishrasanjeev224]

Hi @jaspervdj-luminal I haven't seen any progress since last couple of weeks. Could you please update and let us know when this issue can be fixed. We are blocked on our migration work due to this issue. Will be appreciated if we prioritise this issue and get this fixed ASAP.

[jaspervdj-luminal]

@mishrasanjeev224 Hey, this fix was included in the 2.4.0 release. Please let us know if this works for your case?