GuardDuty update member accounts' detectors

[dpiddock]

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

Description

Currently Terraform cannot change the status of detectors of member accounts in a GuardDuty multi-account setup. For example enabling or disabling the S3 Protection.

Member accounts are not allowed to change their own detector status.

New or Affected Resource(s)

• aws_guardduty_member
• or maybe as a new resource?

Potential Terraform Configuration

resource "aws_guardduty_member" "member" {
  account_id  = "123456789012"
  detector_id = aws_guardduty_detector.primary.id
  email       = "required@example.com"
  invite      = false

  datasources {
    s3_logs {
      enable = true
    }
    kubernetes {
      audit_logs {
        enable = false
      }
    }
    malware_protection {
      scan_ec2_instance_with_findings {
        ebs_volumes {
          enable = true
        }
      }
    }
  }
}

References

• https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html
• https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/guardduty#Client.UpdateMemberDetectors

[michael-strigo]

Stumbled upon this issue myself.

I think it might make sense to have a aws_guardduty_memeber_detectors resource which can allow managing the detectors of member accounts whether these were added manually via invite or auto-added by AWS Organization.

Alternatively, can be done like the suggestion above, but removing the required email configuration.

[fdutheil]

Hi,
This NEEDS to be implemented, there is no way to workaround this (delegated admin account is the only one to update the members accouts settings, and TF doesn't expose any way to do this).

https://docs.aws.amazon.com/guardduty/latest/ug/malware-protection.html#configure-malware-protection-multi-account

[tide-jamiegwatkin]

We also really need this.

[dpiddock]

Release 5.20.0 added an aws_guardduty_detector_feature #31463 which supports configuring all the currently available detectors, but only for standalone or admin accounts. Still need a similar feature for member accounts.

[nthienan]

Really need this

[vinay2107]

We also need this.

[autero1]

I'm drafting a PR for this. Initial plan is to add a resource like this:

resource "aws_guardduty_member_detector_feature" "test" {
  account_id. = "123456789012" # Member acct ID
  detector_id = "asdf" # Delegated admin acct detector id
  
  name   = "EKS_RUNTIME_MONITORING"
  status = "ENABLED"

  # Optional
  additional_configuration {
    name   = "EKS_ADDON_MANAGEMENT"
    status = "ENABLED"
  } 
}

Would appreciate input for the following:

Deleting resources
A lot of the existing GuarDuty Org features, such as guardduty_organization_configuration_feature, just remove the resource from state without disabling the resource. Haven't really looked into why this is, maybe there's no explicit delete API. Which is the case here, as well.

Which would be better?

1. Just remove the resource from state. If you want to actually disable the feature, you can always set status = "DISABLED" and not remove the resource from your configuration.
2. Set the feature (and if present, the additional_configuration) status = "DISABLED"

Acceptance Testing

There are multiple preconditions here:

• AWS Organizations enabled with all features
• Delegated admin account (could be the same as the Org root account)
• Not sure, but would possibly need another account that's a member account

Not 100% sure but I think you cannot use the API to update the delegated admin account itself. At least in the AWS console, the accounts listed does not contain the delegated admin account and you enable the features in a different place.

What in your opinion would be the best way to write the acc tests?

1. Try to bootstrap all preconditions in the acc test. I don't have any spare AWS accounts w/o AWS Organizations set up, so that would be a lot of work with accounts.
2. Just have the preconditions stated in the acc test and skip the bootstrapping.

[kstrauser]

I’d much prefer 1: just delete the resource. It’s consistent with the way other resources are handled. More important, it’s usually obvious if you delete, say, an EC2 instance. Hey, my thing stopped working! If you turn off a feature here through misconfiguring TF, everything will continue to work, except that you’ll lose the security features you thought were monitoring your accounts.