Guardduty enabled on unmanaged OUs

[senyberg]

Describe the bug When enabling Guardduty in LZA, it will also enable it in accounts that are part of organization but in OU that is explicitly set to not be part of LZA config:

organizationalUnits:
  - name: Security
  - name: Infrastructure
  - name: Suspended
  - name: Workloads
  - name: Workloads/Test
  - name: Workloads/Production
  - name: Unmanaged
    ignore: true

You cannot deploy accounts from LZA in unmanaged OUs, and you cannot either use Guardduty deploymentTargets since it is not part of LZA configuration. This means that with LZA you are stuck with Guardduty on all accounts, unless you manually want to change them from API/Console.

To Reproduce

• Create OU in LZA with ignore: true flag
• Create account in OU from AWS Organizations (for example)
• Enable Guardduty in LZA

Expected behavior LZA should not deploy Guardduty in Unmanaged OU's.

Please complete the following information about the solution:

• [x] Version: v1.9.1
• [x] Region: eu-west-1

[richardkeit]

@senyberg - what is your security config?

FYI autoEnableOrgMembers is default to true.

I would expected that if deploymentTargets was used that you'd be able to configure your expected behaviour

[senyberg]

@richardkeit So I have already made changes to the config since that, so I cannot copy exactly how it looked.

But at the time of configuring Guardduty, I did not have autoEnableOrgMembers set explicitly (which means it would be true), and no deploymentTargets set either.

With my logic, if an OU is not managed by LZA, I expect it to not deploy any resources to those accounts either. Which is why I think one should not have to use deploymentTargets or autoEnableOrgMembers parameters.

[richardkeit]

Hi @senyberg ,

That's not how enabling features work through AWS Organizations supported services - here's some further reading on it.

https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html

Just providing a different viewpoint for consideration

[senyberg]

@richardkeit I do understand what you mean, but at the same time feels a bit inconsistent. If I want to create a landingzone managed by LZA, which also manages the service (in this case Guardduty), personally I feel like it should only apply to those accounts that are managed by LZA. Even more so since you can do it, with parameters.

Maybe the current implementation is just as intended, but to me it does not feel consistent across the board.

If this is not a valid issue, it can be closed. But I would like to also see documentation on stuff like this.