Use ternary instead of && for boolean logic

[jeffgran]

Logical binary operators don't short-circuit: hashicorp/terraform#24128

Summary

In terraform, logical binary operators don't short-circuit: hashicorp/terraform#24128

So while the code here looks like each branch of the conditional check is checking to see whether the second check is necessary, terraform (or more strictly/accurately, HCL) is always evaluating all of the branches of the boolean expression.

The problem with that is that, for example, if you don't need to check the var.bucket_sse_key_arn because var.use_existing_cloudtrail is true, but your var.bucket_sse_key_arn that you passed in is referencing another resource, this will create a terraform error because it can't determine the ultimate value of this create_kms_key local which is used to determine the count of the kms key resource.

And so, we get this error:

│ Error: Invalid count argument
│
│   on .terraform/modules/aws_cloudtrail/main.tf line 36, in resource "aws_kms_key" "lacework_kms_key":
│   36:   count                   = local.create_kms_key
│
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources
│ that the count depends on.

By using the ternary operator instead of the && operator, we effectively make it "short circuit" and not evaluate the second part of the boolean expression, while retaining the same logic as before. This allows combinations of variables that would disable the kms key from being created to work without the error above.

How did you test this change?

We used this forked code in our production terraform module where we were trying to upgrade to v2.x from v0.2, and this unblocked us from upgrading.

Issue

This is related to #81 but does not completely fix that issue. It does fix the case where you are using an existing cloudtrail resource, i.e. var.use_existing_cloudtrail = true, because then it doesn't need to check the bucket_sse_key_arn variable.

A further fix would be required to enable passing a custom bucket key and using an existing cloudtrail. Probably we need to add a var.use_existing_bucket_sse_key variable.

[dmurray-lacework]

make it so!