-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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
provider/aws: Add "enable_logging" to CloudTrail resource #4010
Conversation
The AWS CloudTrail resource is capable of creating CloudTrail resources, but AWS defaults the actual logging of the trails to `false`, and Terraform has no method to enable or monitor the status of logging. CloudTrail trails that are inactive aren't very useful, and it's a surprise to discover they aren't logging on creation. Added an `enable_logging` parameter to resource_aws_cloudtrail to enable logging. This requires some extra API calls, which are wrapped in new internal functions. For compatibility with AWS, the default of `enable_logging` is set to `false`.
Add acceptance tests for creation, enable, and disable logging. Add option to docs and example.
The purpose of the first test of enable_logging wasn't quite clear. It's future-proofing against the assumptions made about AWS behavior.
Thanks a lot for catching this! Since I wrote the implementation for TF, I didn't get to actually test it thoroughly in practice yet (except in the acceptance test), hence I did not realise it's disabled by default. 😮 Even though it may be considered as a breaking change, I would rather enable it by default. |
"enable_logging": &schema.Schema{ | ||
Type: schema.TypeBool, | ||
Optional: true, | ||
Default: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can keep the field name, just change this to Default: true
and it should be good to go. 😃
I waffled on whether to enable by default or not. It seems like the right thing to do, under the assumption that if you declare a trail you'd like to use it. However, I also figured that matching AWS behavior and not being surprising was a good thing. (of course, AWS behavior was the real surprise here...) I ended up deciding to just add it with the AWS behavior, and note the default. Changing the default to However, if it's desired to default to |
I would enable it by default. Also CloudTrail wasn't released yet, so it won't actually be breaking anything as long as we'll make it until Monday, when we're most likely cutting the next release. I think many people rely on CloudTrail as one of the security mechanisms and I believe they'd rather have this enabled than disabled. The pricing is also a good argument why rather enable it and why it shouldn't matter too much if you'd enable it by accident: https://aws.amazon.com/cloudtrail/pricing/
|
Yes, I agree. Default I'll rework the tests to expect that default and change the doc entry. I'll get an update to the PR in today so hopefully the CloudTrail stuff can all go together on Monday. |
The default for `enable_logging`, which defines whether CloudTrail actually logs events was originally written as defaulting to `false`, since that's how AWS creates trails. `true` is likely a better default for Terraform users. Changed the default and updated the docs. Changed the acceptance tests to verify new default behavior.
Tested on my own configs, does what it should. Also updated the docs in that commit. Reworked the acceptance tests, they still look good:
|
@@ -84,6 +89,11 @@ func resourceAwsCloudTrailCreate(d *schema.ResourceData, meta interface{}) error | |||
|
|||
d.SetId(*t.Name) | |||
|
|||
// AWS CloudTrail sets newly-created trails to false. | |||
if v, ok := d.GetOk("enable_logging"); ok && v.(bool) { | |||
cloudTrailSetLogging(conn, v.(bool), d.Id()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add error checking here, please? Otherwise any error coming out from cloudTrailSetLogging
would be ignored.
@pforman Thanks for the quick update, I appreciate it. Acceptance tests are 👌 I left you some comments there, some are more serious (error checking) some are just nitpicks. It would be nice if you managed to fix the error checking at least. I will check this PR again tomorrow morning (UK time) and may eventually pick it up (in case you would not get chance to look at it by that time). |
Thanks for the thorough review, looks like I dropped some errors there, which is bad. I'll see if I can get an update in. If not (or if I do and there's still something off), go ahead and pick it up. I'm heading out of town for a while tomorrow, so I won't be back immediately to work on it anyway. It would be good to see it in 0.6.7 with the problems fixed. |
Some error-checking was omitted. Specifically, the cloudTrailSetLogging call in the Create function was ignoring the return and cloudTrailGetLoggingStatus could crash on a nil-dereference during the return. Fixed both. Fixed some needless casting in cloudTrailGetLoggingStatus. Clarified error message in acceptance tests. Removed needless option from example in docs.
When adjusting the types to prevent casting, I didn't change the error message to handle the pointer change. "go tool vet" caught this.
Okay, I think I handled everything in the review.
If there's anything else that you see, please feel free to fix it, I'll be on the road tomorrow and won't have a chance to update it before 0.6.7. |
provider/aws: Add "enable_logging" to CloudTrail resource
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
I was working with the CloudTrail resource (#3094, merged for release in 0.6.7) and discovered that AWS creates CloudTrail trails with logging disabled by default. The user needs to click the button in the console, or send a
cloudtrail:StartLogging
API call to begin using the trail.Terraform will create the trail, but had no ability to enable (or monitor the ongoing state of) logging on the trail resource.
I didn't want that to be managed or changed outside my TF config, so I wrote this PR to add an
enable_logging
parameter to the CloudTrail resource. It requires extra API calls (StartLogging
to enable orStopLogging
to disable), so I wrapped those in helper functions insideresource_aws_cloudtrail.go
. The CRUD operations use these to try to do the right thing.The default is still
false
to match existing AWS behavior. I wrote some acceptance tests for enabling and disabling logging, and added the option to the documentation.Please look through the implementation and let me know if there's something that looks off, I'm happy to fix it or rework it if necessary. Big thanks to @radeksimko for writing the resource in the first place.
make testacc TEST=./builtin/providers/aws TESTARGS='-run=CloudTrail' 2>/dev/null
go generate ./...
TF_ACC=1 go test ./builtin/providers/aws -v -run=CloudTrail -timeout 90m
=== RUN TestAccAWSCloudTrail_basic
--- PASS: TestAccAWSCloudTrail_basic (15.53s)
=== RUN TestAccAWSCloudTrail_enable_logging
--- PASS: TestAccAWSCloudTrail_enable_logging (19.95s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 35.499s