This post discusses the new Delegated Admin concept, which makes it easier to enable GuardDuty and Access Analyzer across an Organization.

With the release of GuardDuty in November 2017, AWS started down a bad path. GuardDuty is a great service that I recommend everyone use, but its use of an invite/accept dance in order to connect accounts was awkward. For every existing account, and for every new account, you’ve had to enable GuardDuty and then go through this multi-step process involving multiple accounts. Many have setup automation to do this (example here), but it is a frustrating burden AWS has placed on the customer instead of simplifying the process on their end.

When you contrast GuardDuty’s flow with the one-time CloudTrail configuration to get setup with an Organization Trail, you’re left scratching your head. Then AWS applied that same awkward invite/accept dance to Security Hub, so it seemed this was just how AWS wanted you to do things (although you could avoid much of the awkwardness by using CloudWatch Events as I discusssed here).

Then on March 30, 2020, AWS announced the concept of a Delegated Administrator for their Access Analyzer service (announcement here), followed by GuardDuty on April 24 (announcement here).

Creating a Delegated Admin for GuardDuty and Access Analyzer

The way this works is in the Organization Master account, for the GuardDuty and Access Analazyer services, you specify a Delegated Admin account. The screen shot below is of the GuardDuty service in one region in the Organization Master.

Contrast that screenshot with the view you get in a normal organization member account.

That new section in the Organization Master account allows you to specify another account, such as your dedicated Security account, to enable GuardDuty across your organization and for all new accounts in the org! This is basically the Organization Trail concept being applied to GuardDuty!!! No more invite/accept for accounts in your same org. You do unfortunately have to do this across all regions though.

This same concept is also used for Access Analyzer.

This is a little weird because the Organization specific configuration is within the services, as opposed to involving the Settings view of the Organization service, like you do for CloudTrail.

Configuring the Delegated Admin account

After setting my Security account as a Delegated Admin for both service, I then need to configure that account. In the GuardDuty service, I’ll see this new button.

Clicking “Enable” shows this pop-up, which you click, and now you’re done! No more Lambdas assuming roles across multiple accounts.

Similarly, for Access Analyzer, you create a new analyzer for you whole Organization.

Doing this from the command-line

From the command-line it looks like in the Org Master you run:

aws guardduty enable-organization-admin-account --admin-account-id SECURITY_ACCOUNT
aws organizations enable-aws-service-access --service-principal guardduty.amazonaws.com
aws organizations register-delegated-administrator --account-id SECURITY_ACCOUNT --service-principal guardduty.amazonaws.com

aws organizations register-delegated-administrator --account-id SECURITY_ACCOUNT --service-principal access-analyzer.amazonaws.com
aws organizations enable-aws-service-access --service-principal access-analyzer.amazonaws.com

And in the Security account you run:

aws accessanalyzer create-analyzer --analyzer-name analyzer --type ORGANIZATION

# For each region...
# Create a detector and then get its detector ID
aws guardduty create-detector --enable
aws guardduty update-organization-configuration --detector-id DETECTOR_ID --auto-enable
aws guardduty create-members --detector-id DETECTOR_ID --account-details EXISTING_ACCOUNTS

Conclusion

This new concept is great as it removes much the burden that AWS had previously been putting on customers.