Logging Stage: Custom::PutPublicAccessBlock failed (access denied)

[jobalbz]

LZA-LoggingStack-XXXXXXXX-ca-central-1 | 54/95 | 4:52:38 PM | CREATE_FAILED | Custom::PutPublicAccessBlock | S3PublicAccessBlock/Resource/Default (S3PublicAccessBlock344F906B) Received response status [FAILED] from custom resource. Message returned: AccessDenied: Access Denied

CloudTrail "eventTime": "2024-01-04T15:05:08Z", "eventSource": "s3.amazonaws.com", "eventName": "PutAccountPublicAccessBlock", "awsRegion": "ca-central-1", "sourceIPAddress": "15.156.75.16", "userAgent": "[aws-sdk-nodejs/2.1374.0 linux/v16.20.2 exec-env/AWS_Lambda_nodejs16.x AwsSolution/SO0199/1.5.2 promise]", "errorCode": "AccessDenied", "errorMessage": "Access Denied", "requestParameters": { "PublicAccessBlockConfiguration": { "xmlns": "http://awss3control.amazonaws.com/doc/2018-08-20/", "RestrictPublicBuckets": true, "BlockPublicPolicy": true, "BlockPublicAcls": true, "IgnorePublicAcls": true }, "Host": "XXXXXXXX.s3-control.ca-central-1.amazonaws.com" },

[jobalbz]

Looks like this SCP (AWSAccelerator-Guardrails-Part-0-Core) which is attached to the LogArchive account is the culprit. The policy has a deny on

"s3:PutAccountPublicAccessBlock",

[rjjaegeraws]

The SCP has a condition statement to allow LZA automation the ability to apply configurations. The custom resource lambda function has a name prefix that would match the condition statement. You should inspect the 'prefix' value applied in your environment.

[jobalbz]

I used the prefix LZA. Are you suggesting i should add this prefix in all SCPs where applicable like the one below?

"ec2:DisableEbsEncryptionByDefault", "s3:PutAccountPublicAccessBlock", "ds:UnshareDirectory", "ram:Delete", "ram:Disassociate", "ram:Update" ], "Resource": "", "Condition": { "ArnNotLike": { "aws:PrincipalARN": [ "arn:aws:iam:::role/cdk-accel-", "arn:aws:iam:::role/AWSA", "arn:aws:iam::*:role/AWSControlTowerExecution" ] } }`

[rjjaegeraws]

The configuration code, in code commit, looks like this:

"Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": ["arn:${PARTITION}:iam::*:role/${ACCELERATOR_PREFIX}*", "arn:${PARTITION}:iam::*:role/${MANAGEMENT_ACCOUNT_ACCESS_ROLE}"]
        }
      }

Which would have the ${ACCELERATOR_PREFIX} replaced with your prefix. By default, the value is 'AWSAccelerator', which would be the prefix of the Role name used by the custom resource lambda.

[jobalbz]

Im using these SCPs here and they dont have the same conditions: /landing-zone-accelerator-on-aws-for-cccs-medium/tree/main/config/service-control-policies)

Where should i grab a good version of the SCPs? Or should i just edit them.

[oliviergaumond]

Hi Joseph, we will soon (1-2 weeks) publish an updated version of the configuration files using the ${ACCELERATOR_PREFIX} replacement variable and allowing the use of a custom prefix and custom deployment role during the installation. In the meantime we suggest that you keep the default options in the Installer Stack, more specifically AWSAccelerator for the accelerator prefix.

Can you also confirm what value you use for managementAccountAccessRole under global-config.yaml?

If you need more assistance with this I suggest you reach out to your AWS Solution Architect or Account Manager so we can further support you with this.

[jobalbz]

Hi Olivier,

Here's the requested value from global-config.yaml. Im using Control Tower as per instruction from our AWS Solutions Architect

managementAccountAccessRole: AWSControlTowerExecution # UPDATE: If using Control Tower, set to AWSControlTowerExecution

I dont think I can wait 2 weeks for the updated configuration files. Instead of changing the prefix, I'd rather add the ${ACCELERATOR_PREFIX} where applicable in the SCPs. What do you think? Or am I better off with renaming the prefix. Im already at the logging stage. How would this affect stacks that are already deployed.

Thanks, Joseph

[oliviergaumond]

You could replace occurrences of AWSA* in the SCP files by ${ACCELERATOR_PREFIX}*. Most occurrences should be on roles used in conditions but you will also find AWSAccelerator references on tags in the SCP as well that need to be updated.

[jobalbz]

There are also occurrences of tag values of AWSA. I also replaced those with ${ACCELERATOR_PREFIX}

"Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/Accelerator": "AWSA"

[oliviergaumond]

This has been fixed in version v1.6.1-a