Looking at setting up GuardDuty for an organization. Any tips on this? Trying to understand if I can run under one script under one AWS profile or if I need to break this up into different scripts.
10/19/2021, 10:00 PM
GuardDuty works per account. You should set it up in a stack that manages the entire account (as opposed to some abstract subset of an account, such as a per-VPC stack).
If you have a stack that manages Control Tower and/or SSO, that would be the place I'd put it.
10/19/2021, 10:09 PM
I don't currently have a stack that manages multiple accounts. Have previously set up AWS SSO manually but just looking at doing GuardDuty at this point. Any tips on creating a stack that manages multiple accounts?
10/19/2021, 10:33 PM
I think you should look for ways to not do that: one project that manages multiple accounts is fine, with one stack per project. GuardDuty won't require you to manage multiple accounts with one stack, afaict.
There are some things that do, like VPC peering.
If you want one stack to manage multiple accounts in this regard, I'd recommend investigating Control Tower first. Essentially, manage just one account (your org root account) and have it manage the others.
But as to your the specific question: a stack that deals with resources in multiple accounts isn't hard, you just have to be extremely strict about requiring that every single resource is explicitly given the correct provider.
If you don't do that, you'll eventually assume that a resource is going into account A, and in fact it's going to account B. And stuff won't work and you'll spend hours investigating.
10/19/2021, 11:06 PM
I think (though definitely not sure) that for GuardDuty, I need to by in the context of the organization master account to delegate another account as the GD-master (OrganizationAdminAccount). Then I think I need to be in the context of the GD-master account to create the primary detectorId and create member accounts (Member). I get the concept of using a provider but not sure how to assume role as we're using AWS SSO. I guess the workaround is to just create 2 different scripts in different folders to do things separately.