Closed andwrobs closed 7 months ago
Voting for Prioritization
Volunteering to Work on This Issue
It already kinda works. Using this configuration enables all runtime monitoring features:
resource "aws_guardduty_detector_feature" "runtime_monitoring" {
detector_id = data.aws_guardduty_detector.main.id
name = "RUNTIME_MONITORING"
status = "ENABLED"
additional_configuration {
name = "ECS_FARGATE_AGENT_MANAGEMENT"
status = "ENABLED"
}
additional_configuration {
name = "EKS_ADDON_MANAGEMENT"
status = "ENABLED"
}
}
resource "aws_guardduty_organization_configuration_feature" "runtime_monitoring" {
detector_id = data.aws_guardduty_detector.main.id
name = "RUNTIME_MONITORING"
auto_enable = "ALL"
additional_configuration {
name = "ECS_FARGATE_AGENT_MANAGEMENT"
auto_enable = "ALL"
}
additional_configuration {
name = "EKS_ADDON_MANAGEMENT"
auto_enable = "ALL"
}
}
The only problem that I noticed is that Terraform will try to reorder additional_configuration
whenever applying changes. I tried putting ECS after EKS and it's the same. The AWS API always returns the additional configuration in the same order that is different from Terraform. Terraform would just need to ignore the order of additional_configuration
and everything would be nice (this feature just needs a documentation update).
It already kinda works. Using this configuration enables all runtime monitoring features:
resource "aws_guardduty_detector_feature" "runtime_monitoring" { detector_id = data.aws_guardduty_detector.main.id name = "RUNTIME_MONITORING" status = "ENABLED" additional_configuration { name = "ECS_FARGATE_AGENT_MANAGEMENT" status = "ENABLED" } additional_configuration { name = "EKS_ADDON_MANAGEMENT" status = "ENABLED" } } resource "aws_guardduty_organization_configuration_feature" "runtime_monitoring" { detector_id = data.aws_guardduty_detector.main.id name = "RUNTIME_MONITORING" auto_enable = "ALL" additional_configuration { name = "ECS_FARGATE_AGENT_MANAGEMENT" auto_enable = "ALL" } additional_configuration { name = "EKS_ADDON_MANAGEMENT" auto_enable = "ALL" } }
The only problem that I noticed is that Terraform will try to reorder
additional_configuration
whenever applying changes. I tried putting ECS after EKS and it's the same. The AWS API always returns the additional configuration in the same order that is different from Terraform. Terraform would just need to ignore the order ofadditional_configuration
and everything would be nice (this feature just needs a documentation update).
Doesn't seem to work for me:
expected name to be one of ["S3_DATA_EVENTS" "EKS_AUDIT_LOGS" "EBS_MALWARE_PROTECTION" "RDS_LOGIN_EVENTS" "EKS_RUNTIME_MONITORING" "LAMBDA_NETWORK_LOGS"], got RUNTIME_MONITORING
expected additional_configuration.0.name to be one of ["EKS_ADDON_MANAGEMENT"], got ECS_FARGATE_AGENT_MANAGEMENT
@cyn110 please make sure you're using the latest provider version (support for this RUNTIME_MONITORING
value was introduced with an AWS SDK update, I believe it was the 5.27.0
release?) and an AWS region that supports this feature.
@gid0 do you still see the ordering error with this solution? If so, what does your workaround look like?
@gid0 do you still see the ordering error with this solution? If so, what does your workaround look like?
Hey, really sorry to comment on a closed issue... but yes there is still this perpetual resource update issue with the latest provider version as of today (v5.39.1
):
The workaround is to use a specific order for the additional_configuration
blocks. The additional trick is that the order must be different between the aws_guardduty_detector_feature
and the aws_guardduty_organization_configuration_feature
resources.
So basically I use:
resource "aws_guardduty_detector_feature" "runtime_monitoring" {
detector_id = data.aws_guardduty_detector.main.id
name = "RUNTIME_MONITORING"
status = "ENABLED"
additional_configuration {
name = "EKS_ADDON_MANAGEMENT"
status = "ENABLED"
}
additional_configuration {
name = "ECS_FARGATE_AGENT_MANAGEMENT"
status = "ENABLED"
}
}
resource "aws_guardduty_organization_configuration_feature" "runtime_monitoring" {
detector_id = data.aws_guardduty_detector.main.id
name = "RUNTIME_MONITORING"
auto_enable = "ALL"
additional_configuration {
name = "ECS_FARGATE_AGENT_MANAGEMENT"
auto_enable = "ALL"
}
additional_configuration {
name = "EKS_ADDON_MANAGEMENT"
auto_enable = "ALL"
}
}
Note the order of EKS_ADDON_MANAGEMENT
and ECS_FARGATE_AGENT_MANAGEMENT
and that it's different in the two resource types.
If the order is not right, terraform plan will always show this change and try to update the resource.
This functionality has been released in v5.40.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.
For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!
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.
Description
As of November 26, 2023, AWS Guard Duty supports Runtime Monitoring for ECS.
aws_guardduty_detector_feature
supports EKS_RUNTIME_MONITORING, but has no option for ECSRequested Resource(s) and/or Data Source(s)
aws_guardduty_detector_feature
Potential Terraform Configuration
References
AWS announcement post
Current GuardDuty Terraform resource
Would you like to implement a fix?
None