aws
[Bug]: AWS Copilot doesn't work in accounts with AWS Control Tower standard Guard Rails enabled
Description:
When CT.S3.PR.2 Guard Rail is enabled (this is a standard guard rail required in pen tests), copilot svc init fails.
Hook failed with message: ValidationError [CT.S3.PR.2]: Require an Amazon S3 bucket to have server access logging configured [FIX]: Set a 'LoggingConfiguration' on the S3 Bucket and optionally set 'DestinationBucketName' to an S3 bucket configured to receive S3 Access Logs.
PipelineBuiltArtifactBucket UPDATE_FAILED - The following hook(s) failed: [ControlTower::Guard::Hook]
Details:
> $ copilot -v
copilot version: v1.34.0
Observed result:
The following resource(s) failed to update: [PipelineBuiltArtifactBucket].
copilot svc init fails to complete successfully.
Expected result:
copilot svc init should work even when standard guard rails packs are enabled.
Hello @craigjbass. Sorry for the churn. Before we fix by adding log configuration to all the buckets provisioned by Copilot, is there anyway you can work this out for example overriding the rule or suppressing the alert?
The rule is set within the organisation root account, and disabling would mean non-compliance with one of the out of the box AWS security standards which we are audited against.
This rule is a proactive guard so it prevents CF templates from being applied if it detects non conforming resources
The challenge I see is how do you create the log bucket with copilot because how do you create a log bucket (without logging on it). I don’t think AWS compliance tools really have thought through IaC.
(We have a log bucket that could be reused that was created before guardrails were configured)
The challenge I see is how do you create the log bucket with copilot because how do you create a log bucket (without logging on it). I don’t think AWS compliance tools really have thought through IaC.
That's a really good question. I guess they would expect users to either use the bucket itself as the log bucket (by not specifying the access log bucket name in the bucket log configuration), or specify an access log bucket (and the log for the access log bucket itself has to be stored in itself).
The rule is set within the organisation root account, and disabling would mean non-compliance with one of the out of the box AWS security standards which we are audited against.
Do we have to either accept all or none? Is it configurable and partially overridable?
either use the bucket itself as the log bucket (by not specifying the access log bucket name in the bucket log configuration)
we found this caused recursive logs