key_statement.conditions breaking change

[leonblueconic]

In 3.1.1 the key_statements attribute that contained a one or more conditions could be defined like:

       conditions = [
        {
          test     = "StringEquals"
          variable = "kms:CallerAccount"
          values   = [local.current_account_id]
        },
        {
          test     = "StringEquals"
          variable = "kms:ViaService"
          values   = ["sqs.${local.current_region}.amazonaws.com"]
        }
      ]

In 4.0.0 this attribute now needs to be called 'condition'. This was not reported as a breaking change in the changelog. It just silently drops the conditions and could potentially grant to wide of an access.

[bryantbiggs]

resolved in #38

[martivo]

Be aware that it will not give any error about it and creates a policy that just does not have the condition at all (more relaxed policy). Would it be possible to add a check for "conditions" in the key_statements and throw error?

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.