-
Notifications
You must be signed in to change notification settings - Fork 9.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
r/aws_securityhub: Add aws_securityhub_product_subscription resource #6921
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple little things, then good to go, thanks @gazoakley!
Create: resourceAwsSecurityHubProductSubscriptionCreate, | ||
Read: resourceAwsSecurityHubProductSubscriptionRead, | ||
Delete: resourceAwsSecurityHubProductSubscriptionDelete, | ||
Importer: &schema.ResourceImporter{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is currently missing acceptance testing and documentation. 😅 I think the current comment in the acceptance testing might be outdated since it looks like the Read
function is implemented just fine below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left this in accidentally - but I might have a misunderstanding about the import process. Do resources need to be able to read/populate all attributes solely from the resource ID? The API doesn't have a way to read back the product_arn
given a product subscription ARN (you can only check a subscription exists). It looks like I might be able to make an import test that works if I specify ImportStateVerifyIgnore: []string{"product_arn"}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yikes, I was conflating product ARNs with product subscription ARNs. Yeah, for imports we need to set all attributes in the Read function or it'll show them as a difference after import (e.g. attribute: "" => "configured-value"
).
We have a few options since the API doesn't have a way to read it back:
- Use ImportStateVerifyIgnore as you mention for now, but it'll have the difference problem noted above
- Make the resource ID two parts, containing both ARNs, then Read has all the information it needs to search for the subscription and properly set product ARN as well
- Or as a potentially crazy idea, if we can assume the production subscription ARN is always derivable from the product ARN (maybe looks possible from at least AWS subscriptions?), switch the resource identifier to the product ARN and calculate the subscription ARN
arn:aws:securityhub:us-west-2::product/aws/guardduty
# Set AccountID
# Replace Resource product with product-subscription
arn:aws:securityhub:us-west-2:ACCOUNTID:product-subscription/aws/guardduty
I'd lean towards including both ARNs in the resource ID for ease, operator friendliness after import, and safer than trying to derive it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about option 3 previously and then ran away scared 🤣 (I think it's doable, but the resource would need to know the current account ID and region to build an ARN and it feels brittle). Option 2 sounds good to me - I'll look at it later today.
testAccCheckAWSSecurityHubProductSubscriptionExists("aws_securityhub_product_subscription.example"), | ||
), | ||
}, | ||
// Import is not supported, since the API to lookup product_arn from a product |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
{
ResourceName: "aws_securityhub_product_subscription.example",
ImportState: true,
ImportStateVerify: true,
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added an import test step, but I've need to use ImportStateVerifyIgnore
:
{
ResourceName: "aws_securityhub_product_subscription.example",
ImportState: true,
ImportStateVerify: true,
ImportStateVerifyIgnore: []string{"product_arn"},
},
|
||
The following attributes are exported in addition to the arguments listed above: | ||
|
||
* `id` - The ARN of a resource that represents your subscription to the product that generates the findings that you want to import into Security Hub. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* `id` - The ARN of a resource that represents your subscription to the product that generates the findings that you want to import into Security Hub.
## Import
Security Hub Product Subscriptions can be imported via the product ARN, e.g.
```sh
$ terraform import aws_securityhub_product_subscription.example arn:aws:securityhub:us-east-1::product/aws/guardduty
```
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ID is the subscription ARN since that's the only thing I can test still exists - I've added an Import section describing it.
Hi @bflad - updated to address review comments 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @gazoakley! Looks great. 🚀 I'm going to merge this as-is and only do the minor testing thing below if its easy and works as expected.
|
||
resource "aws_securityhub_product_subscription" "example" { | ||
depends_on = ["aws_securityhub_account.example"] | ||
product_arn = "arn:aws:securityhub:${data.aws_region.current.name}:733251395267:product/alertlogic/althreatmanagement" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just noting here for future posterity and not that we don't like our friends over at AlertLogic, but its a little bit of a bummer that the AWS services are automatically subscribed for acceptance testing purposes since they are effectively free, assumed stable for a long while, and doesn't involve an extra EULA. (I'm a little surprised the API doesn't require accepting the EULA first.)
I'll try to switch to using a PreConfig
to disable something like GuardDuty and re-enable it here in the configuration, but if that doesn't go as well as I'd expect, the pricing for this service is fine for the (presumably single hour) time it would be billed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉 7cdbfcf
This has been released in version 1.54.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. |
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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
Partly addresses #6674
Changes proposed in this pull request:
aws_securityhub_product_subscription
Output from acceptance testing: