Attempting to test terraform resource property/attribute is set to particular value

[TrickMcCarthy]

I am attempting to validate that resource attribute values are in acceptable range or set to particular value, but there is no step to support this use case. How can the below type of feature file be written?
https://www.terraform.io/docs/providers/aws/r/rds_cluster.html

So I should be able to verify that the value is being set to specific or some range, for any of the resource attributes below.(Same for any other terraform resource)
resource "aws_rds_cluster" "default" {
cluster_identifier = "aurora-cluster-demo"
engine = "aurora-mysql"
engine_version = "5.7.mysql_aurora.2.03.2"
availability_zones = ["us-west-2a", "us-west-2b", "us-west-2c"]
database_name = "mydb"
master_username = "foo"
master_password = "bar"
backup_retention_period = 5
preferred_backup_window = "07:00-09:00"
}

Scenario Outline: Retention Period defined
Given I have aws_rds_cluster defined
Then it must contain <retention_rules>
Then its value must be greater than 15

    Examples:
        | retention_rules | 

[eerkunt]

Hi @TrickMcCarthy,

Thanks for reporting this! We will improve the step that

When I {operator} it`

where we only support count at the moment. We will also add read to that, then you can use that step before checking the value.

[eerkunt]

Hello @TrickMcCarthy,

terraform-compliance 1.0.17 has the feature where you can compare the values with steps. Here is an example feature/scenario for your situation ;

Feature: Test for https://github.com/eerkunt/terraform-compliance/issues/120

  Scenario: Ensure backup retention period is defined
    Given I have aws_rds_cluster defined
    Then it must contain backup_retention_period
    And its value must be greater than 15

[eerkunt]

Could you please try and let me know if this works for you with 1.0.17 ? Thanks!

[TrickMcCarthy]

Hi Eerkunt,

It's working now thank you for the addition. Negative and Positive test results below.
It doesn't work with terraform 0.11.xx as this does not support the terraform show command conversion to json argument.

Observation: It seems a long winded way to run terraform-compliance to have to produce the plan and then convert it. I preferred passing in the location of the tf files and having this all done in the background. I see this as a deterrent for usability. Please consider making this unnecessary by going back to original method of passing the terraform module folder and performing the json conversion in the background. Perhaps using terraform go library or https://github.com/kvz/json2hcl

terraform-compliance v1.0.19

Running Negative test

In order to provide DR

As engineers
We are required to enable backups with 33 day retention period

Scenario: Ensure backup retention period is defined
    Given I have aws_rds_cluster defined
    Then it must contain backup_retention_period
    And its value must be greater than 32
      AssertionError: 5 is not more than 32

1 features (0 passed, 1 failed)
1 scenarios (0 passed, 1 failed)
3 steps (2 passed, 1 failed)
Run 1562678221 finished within a moment

Running Positive Test
In order to provide DR
As engineers
We are required to enable backups with 33 day retention period

Scenario: Ensure backup retention period is defined
    Given I have aws_rds_cluster defined
    Then it must contain backup_retention_period
    And its value must be greater than 32

1 features (1 passed)
1 scenarios (1 passed)
3 steps (3 passed)

[eerkunt]

Hello @TrickMcCarthy,

Thanks for trying out!

Unfortunately, there are many reasons why terraform-compliance requires a plan output. We had many problems with parsing HCL (while there were no HCL2 out) especially on interpolations and dynamic values.

E.g. you may read a value from aws_ssm_parameter_store and may use it as a variable somewhere. Terraform gets these data ( and many more ) while creating a Plan, since these are required to proceed.

Having this kind of functionality would require not only lexing HCL2 and implement ALL interpolations that terraform has already, but also fetching dynamic values based on specific resource types.

This was a general problem, not only terraform-compliance's. Luckily, terraform contributors and Hashicorp listened to us and created an interface where external tools can use to tap data that terraform will process on a plan.

Due to this problem - which is not the only one, tools that are dealing with HCL2 usually completely changed themselves in order to adapt new terraform.

Unfortunately, there is no plan to process HCL2 directly in the roadmap for now.

[eerkunt]

Closing the issue, since it is fixed already. Thanks again!