"You don't have permissions to access this resource." in SecurityAudit stack

[andreprawira]

Describe the bug
We have an AWS account that before we deploy LZA, its already our delegated administrator of SecurityHub. Then, we enabled securityhub and designated that account as the administrator. Keep in mind this isnt the Audit Account, this is our security-config.yaml

centralSecurityServices:
  delegatedAdminAccount:  <already-existsting-securityhub-administrator-account-not-Audit-Account>
  securityHub:
    enable: true
    regionAggregation: true
    excludeRegions: []
    standards:
      - name: AWS Foundational Security Best Practices v1.0.0
        enable: true
        controlsToDisable:
          - IAM.1
          - EC2.10
          - Lambda.4
  ssmAutomation:
    excludeRegions: []
    documentSets: []

when we deploy the pipeline, it passes the build stage, but fails at the SecurityAudit stack, here is the build log

AWSAccelerator-SecurityAuditStack-<Audit-Account-ID>-us-east-1 | 5/10 | 8:18:50 PM | CREATE_FAILED        | Custom::SecurityHubCreateMembers     | SecurityHubMembers/Resource/Default (SecurityHubMembers2A2B77C4) Received response status [FAILED] from custom resource. Message returned: AccessDeniedException: You don't have permissions to access this resource.

Whats interesting is that the failed SecurityAudit Stack is applied to the Audit Account, not the account that we delegated as the SecurityHub Administrator account. Nowhere in the LZA config we mention the Audit Account to serve as the delegated security purposes, we only mention it in accounts-config.yaml under mandatoryAccounts. Additionally, if i scroll up on the build log, i see this

Assuming role arn:aws:iam::<audit-account-id>:role/OrganizationAccountAccessRole for 3600 seconds
--
171 | AWSAccelerator-SecurityAuditStack-<audit-account-id>-us-east-1: deploying... [1/1]
172 | AWSAccelerator-SecurityAuditStack-<audit-account-id>-us-east-1: creating CloudFormation changeset...

When i manually assume that role from the management account to the Audit Account and poke around the SecurityHub console, i dont see any permission denied, and SecurityHub in Audit Account is already up and running.

To Reproduce

1. have an account that serves as the securityhub delegated administrator
2. add that account in LZA configuration
3. pipeline will fail with that error

Expected behavior
Pipeline should be running just fine as use our own account that we use as the delegated SecurityHub admin, not the Audit Account.

Please complete the following information about the solution:

• Version: v1.10.0
• Region: e.g. us-east-1
• Was the solution modified from the version published on this repository? yes
• If the answer to the previous question was yes, are the changes available on GitHub?
• Have you checked your service quotas for the services this solution uses? yes, its got nothing to do with that
• Were there any errors in the CloudWatch Logs? yes, i posted the error

[andreprawira]

i checked cloudtrail event in the audit account and i found that there is an EnableSecurityHub event with

"responseElements": {
        "Type": "ResourceConflictException",
        "RequestId": "23c9964b-f609-45b2-9ab9-f7ccac6a779c",
        "Message": "Account is already subscribed to Security Hub",
        "Code": "ResourceConflictException"
    },

, then i manually disabled the securityhub and reran that failed stack, it failed again with the same exact error, but when i went to cloudtrail event, i found a new EnableSecurityHub event with just

"responseElements": null,

no error code whatsoever, and checked back securityhub, its enabled. WTH??

[mgroff2]

I think the core issue here is that the stack that is being created is not being created / targeting the correct account.

In the security-config.yaml we have this where we are trying to use a custom security account and not the audit account:

centralSecurityServices:
  delegatedAdminAccount: CustomSecurityAccount

However, the AWSAccelerator-SecurityAuditStack launches in the Audit Account regardless of the source config file. This is the core of the problem.

We are launching with the above config, but finding this stack after the stage runs:
AWSAccelerator-SecurityAuditStack--us-east-1 and not AWSAccelerator-SecurityAuditStack--us-east-1

It's as if the source config is not being respected and the audit account is hardcoded here regardless of the config.

Thoughts?