Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial updates for supporting s3 bucket logging targets. #302

Merged
merged 4 commits into from
Apr 15, 2021

Conversation

jgadling
Copy link
Contributor

Summary

Add support for logging S3 access to another bucket or prefix to the private bucket module.

Test Plan

I generated a tf file that created two buckets (a content bucket, and a logging bucket) and set the logging config of one bucket to refer to the other. The logging config in the plan had logging enabled for the content bucket and disabled for the logging bucket.

Tests pass.

References

(Optional) Additional links to provide more context.

Comment on lines +113 to +119
dynamic "logging" {
for_each = var.logging_bucket == null ? [] : [var.logging_bucket]
content {
target_bucket = var.logging_bucket.name
target_prefix = var.logging_bucket.prefix
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you know what's the difference between this and cloudtrail logs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's a pretty interesting comparison: https://www.netskope.com/blog/aws-s3-logjam-server-access-logging-vs-object-level-logging

It looks like cloudtrail is more complete and more reliable, but also more complicated to configure.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a table in here that I used to determine that S3 logs was the way forward: https://docs.aws.amazon.com/AmazonS3/latest/userguide/logging-with-S3.html. Ultimately it was a combination of ease to set up (took me just a few minutes to set up and start querying) plus the fact that the S3 logs contain more useful information for us (i.e. Object Size, Total Time, Turn-Around Time, and HTTP Referer).

dynamic "logging" {
for_each = var.logging_bucket == null ? [] : [var.logging_bucket]
content {
target_bucket = var.logging_bucket.name
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't know if it's better to do each.name/each.prefix, or leave it like this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I could go either way as well. I think the each syntax is a little bit more confusing though for an iterator where we'll always have 0 or 1 loops.

@jgadling jgadling merged commit c0c5731 into main Apr 15, 2021
@jgadling jgadling deleted the jgadling/bucket-logging branch April 15, 2021 23:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants