Establishing trusted access between AWS Organizations and Inspector v2

Hello,

If you can provide insight, I’d greatly appreciate it.

I’m looking to use the newly-released Inspector v2 terraform resources, which includes establishing an integration between Inspector and AWS OrganizationsL Terraform Registry.

When one is integrating a service with AWS Organizations, typically one must enable trusted access between the service (Inspector v2 in this case) and Organizations. When using SDKs/CLI, this would entail “explicitly calling the EnableAWSServiceAccess operation and providing the service principal as a parameter”, according to AWS documentation: Amazon Inspector and AWS Organizations - AWS Organizations

The terraform documentation for the Inspector v2 resource blocks isn’t clear on how trusted access is established. Does anyone know if one of these blocks establishes trusted access on the backend or if we have to do it manually over CLI/AWS console?

Thank you very much!

2 Likes

Hi there,

I am thinking about the same matter lately. How did you manage to integrate it? I have found that the delegation is supposed to be done with a one-time aws cli command, so I am headed that way.

aws organizations enable-aws-service-access --service-principal inspector2.amazonaws.com
1 Like

I’m facing the same question currently, only difference is that I would like to enable the RAM service.
I found the aws_organizations_organization resource which provides the aws_service_access_principals parameter, which seems to be the parameter to enable specified services in the organization.

Nonetheless, there is a big warning above this resource in the terraform docs that the service enablement should happen only via AWS console, cli or API equivalents. I mean terraform is using those, but in AWS examples they also use the one time aws cli command as you proposed…

So I would be highly interested in an answer on this topic what the right way to enable services is…

Links and Code Snippet:

resource "aws_organizations_organization" "org" {
  aws_service_access_principals = [
    "cloudtrail.amazonaws.com",
    "config.amazonaws.com",
  ]

  feature_set = "ALL"
}

Offical Terraform provider doc: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/organizations_organization

AWS Sample to enable GuardDuty in an organization: https://github.com/aws-samples/amazon-guardduty-for-aws-organizations-with-terraform/blob/main/enable-gd/modules/guardduty-baseline/versions.tf

I think it’s worth trying it. Can’t see why that should be a problem.

That being said, there are things you probably should bear in mind though:

  • if you created the organization outside of Terraform, you’ll need to import it first
  • after importing it, changes made outside of Terraform will be overwritten the next time you apply your project, so Terraform becomes the sole manager of that resource

If that’s not an issue for you, I’d say go ahead and try it out. The worst that can happen is it doesn’t work and you have to do it anyway via the AWS CLI.

1 Like

Yes thats exactly what I did now.
Import and Service Enablement worked as expected. I’m now waiting for the member Account to confirm that the service can be used as intended.
I just did a quick check in the member accounts and I’m not sure if it works, because I didn’t find the Service-Linked role which I thought should be automatically created in each member Account as soon as the trusted access is enabled…
Lets see, I’ll keep you posted.

1 Like

Yes, you need to wait for the owners of the accounts that weren’t provisioned through AWS Organizations to accept the request before the role can be created (but should be created immediately for accounts provisioned via Organizations)