aws_securityhub_member always replaces on apply even on no change

[sunilkumarmohanty]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform AWS Provider Version

aws provider version - 4.9.0 terraform version - 1.0.9

Affected Resource(s)

• aws_securityhub_member

Terraform Configuration Files

Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.

resource "aws_securityhub_member" "this" {
  account_id = "redacted"
  email      = "redacted@example.com"
}

Expected Behavior

There should be no changes in plan if no configuration has changed.

Actual Behavior

On re-running terraform plan or apply after first successful apply, the plan shows that the resources will be replaced even though nothing has changed.

-/+ resource "aws_securityhub_member" "this" {
      + email         = "redacted@example.com" # forces replacement
      ~ id            = "redacted" -> (known after apply)
      - invite        = true -> null # forces replacement
      ~ master_id     = "redacted" -> (known after apply)
      ~ member_status = "Enabled" -> (known after apply)
        # (1 unchanged attribute hidden)
    }
Plan: 1 to add, 0 to change, 1 to destroy.

Steps to Reproduce

1. terraform apply
2. do not make any changes and run terraform plan or terraform apply

[justinretzolk]

Hey @sunilkumarmohanty 👋 Thank you for taking the time to raise this! So that we have all of the necessary information in order to look into this, can you supply debug logs (redacted as necessary) as well?

[iamperson347]

We are receiving a similar issue. We have two fields that appear to be "forcing replacement."

Email (Shows current value as empty) invite (show current vault as true)

Our use case is that we are trying to add an AWS org member to security hub (without turning on "auto-enable" ). It seems this resource might not be handling that use case correctly, but I don't know if this matches OPs use case.

[walidkhlg]

I'm having the same issue aswell with the "email" and "invite" forcing replacement. For now, i'm adding a lifecycle ignore_changes on these 2 attributes to bypass it.

[benkelly86]

Any update on this? We're experiencing the same issue...

[justinretzolk]

Hey @benkelly86 👋 Thank you for checking in on this. Unfortunately, I'm not able to provide an estimate on when this will be looked into due to the potential of shifting priorities (we prioritize work by count of ":+1:" reactions, as well as a few other things). For more information on how we prioritize, check out out prioritization guide.

[dpiddock]

I think the underlying cause is the same as #21243. This is what I ended up using:

resource "aws_securityhub_member" "member" {
  account_id = "123456789012"
  email      = "does@not.matter" # Ignored by AWS API but required by provider
  invite     = false

  lifecycle {
    ignore_changes = [
      # AWS API says `email` is optional and is not used in organizations, so
      # not returned by the ListMembers query.
      # Terraform provider currently marks it as required which causes a diff.
      email,
      # `invite` is only to be true for non-organization members. But Terraform
      # updates it based on `member_status`
      invite,
    ]
  }
}

Unfortunately this also means that terraform does not detect when the member account is manually removed because of the logic used: https://github.com/hashicorp/terraform-provider-aws/blob/600a6c443a6253306b4bc56f4fa1412acddda7ac/internal/service/securityhub/member.go#L134 The resource needs serious attention to make it usable for organizations

[AzySir]

@justinretzolk This is a core service of the AWS Landing Zone / Platform Architecture - not everyone is setting up a Landing Zone daily... (or a SecurityHub instance...) The thumbs up system won't be reflective of the importance here..

Thanks for raising this @sunilkumarmohanty