Checking terraform aws to define logging on bucket causing endless loop of define new bucket for logging untill ignore block

[LupovichRan]

Checking terraform aws to define logging on bucket causing endless loop of define new bucket for logging untill ignore block
this is resolved when you put "ignore block" on the logging bucket - what would be your suggested approach on this ? I don't think "ignore block" as "happy flow" is good practice - WDYT?

[rafaela-soares]

Hi, @LupovichRan!

Can you detail a little more, please?

[LupovichRan]

Yeah, sure
@rafaela-soares
You have this check when s3 bucket missing logging attribute, fixing this is adding s3 bucket to get the logs, but the new "log" bucket than again request logging, here you go for endless loop of bucket create untill you put ignore block on last logging bucket,
https://github.com/Checkmarx/kics/blob/master/assets/queries/terraform/aws/s3_bucket_logging_disabled/query.rego

WDYT?

[rafaela-soares]

Hello, @LupovichRan!

Can you give us an example, please?

[LupovichRan]

https://github.com/Checkmarx/kics/blob/master/assets/queries/terraform/aws/s3_bucket_logging_disabled/test/negative1.tf look on target bucket in logging, in order to comply this target bucket needs to be created, and it will fall to the same tests that made you create it at first place , creating logs bucket will miss logging , you will add target bucket and then again it's recursive

[rafaela-soares]

Hello again, @LupovichRan!

I understood now. Thank you so much for explaining. We will take a look as soon as possible!

[kaplanlior]

As a best practice I would expect a bucket to either have logs enabled, or a tag that indicates it gathers logs for another bucket.

Another check can be in a case a bucket that collect logs has logs enabled , which as Ran said would cause a loop.
e.g. Bucket A has logs enabled and saved in Bucket B. So we check to verify Bucket B has logs disabled.

Makes sense ?

[nunoocx]

We are checking whether the bucket has logging or not.
In case the bucket has no logging we need additionally to check whether it is referenced as the target bucket of some other bucket logs.
This should stop the loop.
It's similar to @kaplanlior suggestion, but focusing on the bucket "function" (normal store or additional logging store).

WDYT?

[LupovichRan]

On complex deployments you might not contain the bucket logging with the source itself, guess that tag specifying it's a logging_bucket would more easier to develop because the element in the same resource and you would not require to check all other s3 resources defined in the tf and it also solves the problem of resources defined in other scope of deployments , WDYT?
So if it has this tag make sure logging disabled or skip test

[nunoocx]

I'm afraid such a tag is both not official and does not semantically enforce anything, so KICS shall not decide based on something only KICS understands as a "fix". Only my opinion, of course :)

You are right about the complex deployments!
But in case the aws_s3_bucket_logging resource is not present in the source, we may be before a static analysis limitation, and possibly a configuration drift as well (if it is done manually or via console).
Do you see other situations where this can be separated from the source?

In these cases it might be better to exclude the result as it is known to be a not exploitable issue, or in the limit exclude the query (the latter, not recommended, though).