fix: Check standard logs in AwsSolutions-CFR3

[georeeve]

Fixes #1876

Opening as a draft as the base implementation works, but I've ran into an issue checking if any CfnDeliverySource resources are defined in the entire stack. I'll explain in a code comment.

I've also had to update aws-cdk-lib to 2.167.0, which is the first version to include outputFormat in CfnDeliveryDestination. As I'm only using this in the tests, am I alright not updating it in the peerDependencies as well?

[georeeve]

@dontirun I'm wondering if you know of a way to check this? I've tried to use Template.fromStack(Stack.of(node)) and then find the resources that way, but that seems to really slow the tests down. Is there a simpler solution that I'm missing?

[georeeve]

I think there might actually be a better solution here. Can we mark all of the CfnDistribution's as NOT_APPLICABLE, add them to a Map and then at the end of the Stack we evaluate and retrospectively mark them as COMPLIANT or NOT_COMPLIANT dependent on whether we've seen a CfnDeliverySource for them? Is there a method of doing that?

[georeeve]

Or maybe we just traverse the entire Stack when we see a CfnDistribution to check if any CfnDeliverySource's are present, similar to what we do in WAFv2LoggingEnabled.

[georeeve]

I've just pushed a commit to match the WAF rule, let me know if you think that's the right solution.

[georeeve]

@dontirun Another question which may be out of scope of this PR, but because the logs templates here need to be deployed to us-east-1 and our main stack is in a different region, we are passing through the distribution's ARN using a StringParameter to avoid cross Stack export errors. Unfortunately when using this, it means that child.resourceArn in this PR resolves to SsmParameterValuedistributionarnC96584B6F00A464EAD1953AFF4B05118Parameter and not directly to the ARN value.

Do you know if there's a way to look up this in the Stack? I can see a resource with the ID of SsmParameterValue:distribution-arn:C96584B6-F00A-464E-AD19-53AFF4B05118.Parameter but obviously it's dropped the :-. characters at some point. We could loop through all of the CfnParameter's manually and store them in a hashmap, but I was wondering if you knew of a more efficient helper method to do it for us? Let me know if any of that doesn't make any sense and I'll try to clarify it some more!

[georeeve]

I've just pushed a commit to resolve SSM parameters as well by traversing the stack again. If it's out of scope for this PR we can just revert the commit, but I think others will also be using parameters to try and avoid any cross-stack reference errors as I detailed above, so it could be useful.