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

provider/aws: Add "enable_logging" to CloudTrail resource #4010

Merged
merged 6 commits into from
Nov 23, 2015

Conversation

pforman
Copy link
Contributor

@pforman pforman commented Nov 21, 2015

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 or StopLogging to disable), so I wrapped those in helper functions inside resource_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

Paul Forman added 3 commits November 21, 2015 00:18
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.
@radeksimko
Copy link
Member

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.
I think it's better to enable by accident than disable.

"enable_logging": &schema.Schema{
Type: schema.TypeBool,
Optional: true,
Default: false,
Copy link
Member

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. 😃

@pforman
Copy link
Contributor Author

pforman commented Nov 21, 2015

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 true will require a small update to the acceptance tests, there's a future-proof test in there to make sure AWS doesn't change their default behavior.

However, if it's desired to default to true, I can adjust it. Fine either way to me.

@radeksimko
Copy link
Member

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/

There is no additional charge for CloudTrail, but standard rates for Amazon S3 and Amazon SNS usage apply. Monthly Amazon S3 charges for CloudTrail usage are typically less than $3 per account for most customers¹. Monthly Amazon SNS charges for CloudTrail usage are typically less than $1 per account for most customers².

@pforman
Copy link
Contributor Author

pforman commented Nov 22, 2015

Yes, I agree. Default true is a sensible position.

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.
@pforman
Copy link
Contributor Author

pforman commented Nov 22, 2015

Tested on my own configs, does what it should. Also updated the docs in that commit.

Reworked the acceptance tests, they still look good:

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 (19.62s)
=== RUN   TestAccAWSCloudTrail_enable_logging
--- PASS: TestAccAWSCloudTrail_enable_logging (26.48s)
PASS
ok      github.com/hashicorp/terraform/builtin/providers/aws    46.122s

@@ -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())
Copy link
Member

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.

@radeksimko
Copy link
Member

@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).

@pforman
Copy link
Contributor Author

pforman commented Nov 22, 2015

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.

Paul Forman added 2 commits November 22, 2015 12:54
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.
@pforman
Copy link
Contributor Author

pforman commented Nov 22, 2015

Okay, I think I handled everything in the review.

  • Added the SetLogging error check in Create (Update had this, but Create didn't...)
  • Added the explicit error check in GetLoggingStatus to avoid nil-dereference
  • Changed the types in GetLoggingStatus to avoid unecessary casting
  • Clarified the error message in the acceptance test
  • Removed needless option in the example.

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.

radeksimko added a commit that referenced this pull request Nov 23, 2015
provider/aws:  Add "enable_logging" to CloudTrail resource
@radeksimko radeksimko merged commit 749fcd4 into hashicorp:master Nov 23, 2015
@ghost
Copy link

ghost commented Apr 29, 2020

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.

@ghost ghost locked and limited conversation to collaborators Apr 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants