Open mrwacky42 opened 2 years ago
I am also experiencing this while updating aws_securityhub_standards_control
resources from "DISABLED"
to "ENABLED"
. The only way I have been able to successfully apply a change is to taint the resource or destroy the stack and rebuild.
resource "aws_securityhub_standards_control" "apig_5" {
control_status = var.ec_apig_5 == true ? "ENABLED" : "DISABLED"
disabled_reason = var.ec_apig_5 == true ? null : "Disabled to comply with company policy."
standards_control_arn = "arn:aws:securityhub:${data.aws_region.main.name}:${data.aws_caller_identity.main.account_id}:control/aws-foundational-security-best-practices/v/1.0.0/APIGateway.5"
}
Initial creation of the resource is successful regardless of a true
or false
variable, but the modification from false
to true
on previously created resources causes the following:
ā Error: error updating Security Hub Standards Control (arn:aws:securityhub:us-east-1:949728939094:control/aws-foundational-security-best-practices/v/1.0.0/APIGateway.5): InvalidInputException: DisabledReason should not be given for action other than disabling control: arn:aws:securityhub:us-east-1:949728939094:control/aws-foundational-security-best-practices/v/1.0.0/APIGateway.5
ā {
ā RespMetadata: {
ā StatusCode: 401,
ā RequestID: "7156eb70-d004-4d41-bd79-58b476a0e0c1"
ā },
ā Code_: "InvalidInputException",
ā Message_: "DisabledReason should not be given for action other than disabling control: arn:aws:securityhub:us-east-1:949728939094:control/aws-foundational-security-best-practices/v/1.0.0/APIGateway.5"
ā }
ā
ā with aws_securityhub_control.aws_securityhub_standards_control.apig_5,
ā on ./main.tf line 38, in resource "aws_securityhub_standards_control" "apig_5":
ā 38: resource "aws_securityhub_standards_control" "apig_5" {
I have confirmed that this can be avoided by making such a statement, but this is a hacky cop-out.
resource "null_resource" "apig_5" {
triggers = {
status = var.ec_apig_5 == true ? "ENABLED" : "DISABLED"
}
}
resource "aws_securityhub_standards_control" "apig_5" {
control_status = var.ec_apig_5 == true ? "ENABLED" : "DISABLED"
disabled_reason = var.ec_apig_5 == true ? null : "Disabled to comply with company policy."
standards_control_arn = "arn:aws:securityhub:${data.aws_region.main.name}:${data.aws_caller_identity.main.account_id}:control/aws-foundational-security-best-practices/v/1.0.0/APIGateway.5"
lifecycle {
replace_triggered_by = [null_resource.apig_5]
}
}
There was an update to allow cloud formation to specify which controls to disable. It might be a good idea to allow terraform to be configured in the same way. https://aws.amazon.com/about-aws/whats-new/2023/06/aws-security-hub-enhanced-management-capabilities-cloudformation https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-securityhub-standard.html
Community Note
Terraform CLI and Terraform AWS Provider Version
Affected Resource(s)
Terraform Configuration Files
Debug Output
N/A
Panic Output
N/A
Expected Behavior
I expect Terraform to re-enable the Security Hub control.
Actual Behavior
I cannot simply re-enable the control, because Terraform is updating the resource in place, and not
null
-ing out the disabled_reason. I get a response:You can see that in the plan that looks something like this:
Steps to Reproduce
terraform apply
the original snippet to disable a Security Hub controlTry to re-enable it with the same resource name: Example of trying to enable the control again:
(I tried also
disabled_reason = null
anddisabled_reason = ""
to no avail. The proposed plan is always only tweaking thecontrol_status
and not thedisabled_reason
.)terraform apply
and š¢ as noted above.Important Factoids
terraform taint aws_securityhub_standards_control.something
seems to do the trick.References
14714 introduced this functionality
19437