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

feat(custom-resources): add logging property to AwsSdkCall and create Logging class #29648

Merged
merged 94 commits into from Apr 14, 2024

Conversation

colifran
Copy link
Contributor

@colifran colifran commented Mar 29, 2024

Reason for this change

SDK v2 and v3 handlers for AwsCustomResource log the event object passed to the handler, API responses, and caught /uncaught errors for each SDK call made. This can potentially result in logging sensitive information that a user may wish to hide. This PR introduces a new logging property on the AwsSdkCall interface that can be used to provide more control over logging in the SDK v2 and v3 handlers on a per SDK call basis. The logging flag is configurable via a new Logging class which exposes two static methods:

  • all: all logging during lambda execution is turned on
  • withDataHidden: hides all logged data associated with the API call response. This includes the raw response as well as the Data field on the response object

Additional logging configurations can be added in the future.

Description of changes

Added a logging flag to the AwsSdkCall interface which is configurable via the new Logging class. The Logging class has an internal render method which renders the specified logging configuration which is passed as part of the create, update, and delete ResourceProperties to the lambda handler. These logging properties are then used throughout the handler to control what is logged based on their value

Description of how you validated changes

  • A new integ test with logging as withDataHidden was added
  • Unit tests to ensure calling render on a Logging instance produces the expected result
  • Unit tests to ensure that using logging with AwsSdkCall while using AwsCustomResource produces the correct CloudFormation template

Checklist


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@github-actions github-actions bot added the p2 label Mar 29, 2024
@aws-cdk-automation aws-cdk-automation requested a review from a team March 29, 2024 08:30
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Mar 29, 2024
This was referenced Apr 1, 2024
@colifran colifran changed the title feat(custom-resources): add property to AwsCustomResourceProps to prevent logging API call response data feat(custom-resources): add optional property to AwsCustomResourceProps to prevent logging API call response data Apr 1, 2024
Copy link
Contributor

@vinayak-kukreja vinayak-kukreja left a comment

Choose a reason for hiding this comment

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

I agree with the changes. But, we should get consensus among the team too about this. Especially stakeholders you have already synced with about this.

/**
* Whether or not to include API response data in the logs for the underlying lambda.
*
* If this value is false, the raw API response and the `Data` field in the response
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should add an example of Response Object here so that we explicitly mention what we will still be logging with this. And also add this to our documentation

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated.

### Custom Resource Examples
### Custom Resource Logging

The underlying lamdda function used by the `AwsCustomResource` construct logs the following information:
Copy link
Contributor

Choose a reason for hiding this comment

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

NIT

Suggested change
The underlying lamdda function used by the `AwsCustomResource` construct logs the following information:
The underlying lambda function used by the `AwsCustomResource` construct logs the following information:

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated.

@@ -607,9 +607,16 @@ new cr.AwsCustomResource(this, 'ListObjects', {
Note that even if you restrict the output of your custom resource you can still use any
path in `PhysicalResourceId.fromResponse()`.

### Custom Resource Examples
### Custom Resource Logging
Copy link
Contributor

Choose a reason for hiding this comment

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

Lets add an example Response Object in these docs

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good call out. This has been updated.

@TheRealAmazonKendra
Copy link
Contributor

Did you close the original PR altogether? I was looking for my comments on it but couldn't find them. This still has the issue of this being a boolean without an option for additional customization.

@colifran
Copy link
Contributor Author

colifran commented Apr 3, 2024

@TheRealAmazonKendra Can you provide more detail on why you think that? We can provide this flag and still keep the door open for additional customization. This flag would only control the logging of the Data field in the response object. Any additional customization could come with a future PR and this flag could be set or unset without blocking a future property that focuses on customization.

Say, for example, we wanted to add something to control log levels. If logApiResponseData is set to false and the log level is DEBUG then CloudWatch Logs still has all errors (caught and uncaught), the event received by the handler, and the response object (just without the Data field). That would open the door for a user to have all the benefits of a DEBUG log level while making an API call that returns sensitive data. Except now they don't have to worry about exposing data in CloudWatch Logs that they want hidden. If that isn't an issue for them then they can ignore logApiResponseData or explicitly set it to true.

The previous PR is linked here. The flag proposed in that PR was too overbearing and would have blocked us from implementing additional customization in the future (as you correctly stated). I don't think this has that problem.

Signed-off-by: Francis <colifran@amazon.com>
Copy link
Collaborator

@aws-cdk-automation aws-cdk-automation left a comment

Choose a reason for hiding this comment

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

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

@colifran
Copy link
Contributor Author

colifran commented Apr 4, 2024

@TheRealAmazonKendra pushed initial changes we discussed offline. To summarize we should provide a Logging class that consolidates all of logging levels into an enum-like class. Additionally, this doesn't need to follow standard logging convention (info, trace, debug, etc.). We can provide something like on, off, and selective where selective would give granular control over logged data to the user.

Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
@colifran colifran changed the title feat(custom-resources): add optional property to AwsCustomResourceProps to prevent logging API call response data feat(custom-resources): add logging property to AwsCustomResourceProps and create Logging class Apr 4, 2024
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
@aws-cdk-automation aws-cdk-automation dismissed their stale review April 4, 2024 05:33

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
@colifran colifran added the pr/do-not-merge This PR should not be merged at this time. label Apr 12, 2024
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Copy link
Contributor

@scanlonp scanlonp left a comment

Choose a reason for hiding this comment

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

One comment as a point of discussion. But overall good from me.

readonly logApiResponseData: boolean;
Copy link
Contributor

Choose a reason for hiding this comment

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

Question on if this property should be optional or not. By the way we have set up the logic with _render(), we will always have a value for this field, so it can be "required".

@colifran and I talked offline, I do not think that this is a problem. The main discussion is at what level we decide to set the default, and having it passed explicitly to the call is fine.

Copy link
Contributor Author

@colifran colifran Apr 13, 2024

Choose a reason for hiding this comment

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

For historical purposes, I want to make sure it is clear that the AwsSdkCall interface referenced above is not a type used in the aws-cdk-lib. Instead, this is a mirror of AwsSdkCall which is defined as part of the AwsCustomResource construct. However, the format of this represents the AwsSdkCall type as it would be received by the v2 and v3 handler, e.g., after render has been called on a Logging instance and all Logging properties are rendered. This interface just exists to provide a strongly typed call in the v2 and v3 handlers.

My opinion is that we should set the default prior to passing the event so that the event properties are visible in the synthesized CloudFormation template.

Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
Signed-off-by: Francis <colifran@amazon.com>
@colifran colifran dismissed vinayak-kukreja’s stale review April 13, 2024 02:08

Code has been updated following this review. The review is no longer relevant to the current code.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: 1f08e31
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@colifran colifran removed the pr/do-not-merge This PR should not be merged at this time. label Apr 14, 2024
Copy link
Contributor

mergify bot commented Apr 14, 2024

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@mergify mergify bot merged commit b049064 into main Apr 14, 2024
15 checks passed
@mergify mergify bot deleted the colifran/response-data branch April 14, 2024 00:24
mergify bot pushed a commit that referenced this pull request Apr 17, 2024
…sSdkCall` in unit tests (#29860)

### Reason for this change

#29648 introduced a change to the `AwsSdkCall` representation used in the v2 and v3 handler code. Our handler unit tests use `satisfies` to validate that the event object satisfies `AwsSdkCall`. All unit tests and the build still pass, but the linter calls out that the event object doesn't actually satisfy `AwsSdkCall`.

#29845 removed the dependency `@aws-cdk/custom-resource-handlers` had on `aws-sdk`. We should add this as devDependency since we're using `aws-sdk` in v2 handler mocks.

### Description of changes

I added `logApiResponseData` property to the event objects being tested to make the event satisfy `AwsSdkCall`. I added `aws-sdk` as a dev dependency. We will remove this as part of the v2 handler removal.

### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS. p2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants