-
Notifications
You must be signed in to change notification settings - Fork 552
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
fix(instrumentation-aws-sdk): remove un-sanitised db.statement span attribute from DynamoDB spans #1748
Conversation
@carolabadeer @blumamir Are you able to review please? This is impacting on our services. It is pushing private database values to traces. |
It is indeed not a good practice to record raw query as By default, this instrumentation should either not record @ramesius Would you be able to add the feature in this PR? |
@srprash Yeah I can take care of that in this PR. I will raise the change with a default implementation that redacts the whole |
This now adds the configuration |
@srprash Good for another review when you are ready. |
@srprash Do you know when you will be able to review this again? |
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.
Overall LGTM.
Added few minor comments.
Sorry for taking long time to review 🙏
const spanAttributes = { | ||
[SemanticAttributes.DB_SYSTEM]: DbSystemValues.DYNAMODB, | ||
[SemanticAttributes.DB_NAME]: normalizedRequest.commandInput?.TableName, | ||
[SemanticAttributes.DB_OPERATION]: operation, | ||
[SemanticAttributes.DB_STATEMENT]: JSON.stringify( | ||
[SemanticAttributes.DB_STATEMENT]: dbStatementSerializer( |
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.
Should we record this attribute if config.dynamoDBStatementSerializer
is undefined
or if the config function returned undefined
?
const spanAttributes = { | ||
[SemanticAttributes.DB_SYSTEM]: DbSystemValues.DYNAMODB, | ||
[SemanticAttributes.DB_NAME]: normalizedRequest.commandInput?.TableName, | ||
[SemanticAttributes.DB_OPERATION]: operation, | ||
[SemanticAttributes.DB_STATEMENT]: JSON.stringify( | ||
[SemanticAttributes.DB_STATEMENT]: dbStatementSerializer( |
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.
Since this function is supplied by the user, the instrumentation should protect. itself from any exception thrown from this function and prevent the patch code from crashing in this case.
You can see many examples in other instrumentations
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.
Most definitely, I will add this in 👍🏻
expect( | ||
JSON.parse(attrs[SemanticAttributes.DB_STATEMENT] as string) | ||
).toEqual(params); | ||
expect(attrs).not.toHaveProperty(SemanticAttributes.DB_STATEMENT); |
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.
I suggest that we also assert it's expected value and not only it's present.
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.
Something missed, thanks for picking it up, will sort that out.
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.
In fact, since this is testing default behaviour and the upcoming change to not set the property if the serializer is not configured this can probably stay as is?
const dynamoDBStatementSerializer: AwsSdkDynamoDBStatementSerializer = ( | ||
_command: CommandInput | ||
): string => { | ||
return SERIALIZED_DB_STATEMENT; | ||
}; |
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.
I suggest adding a test where this serializer throw an exception to verify the instrumentation do not crash in this case
); | ||
}); | ||
|
||
it('should properly execute the db statement serializer for CreateTable operation', done => { |
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.
What is the gain from testing this feature with few operations? is there anything in the code that should behave differently based on the operation that determines how to serializer is executed?
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.
Probably a little excessive in hindsight.
Thinking about https://github.com/open-telemetry/opentelemetry-js-contrib/pull/1748/files/52d09b71cc206a6a40a77cfcf7ab69f7809805d2#r1384667968 multiple tests that assert the operation would probably be the correct direction.
export type AwsSdkDynamoDBStatementSerializer = ( | ||
commandInput: CommandInput | ||
) => string | undefined; |
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.
I wonder if the serializer should also get the operation
to be able to properly sanitize. I guess the sanitization logic can probably work differently for different operations?
This can also be added in the future if someone brings up the need.
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.
I like the suggestion. As pointed out elsewhere, the sanitize function is supplied as part of the public API so I think including operation
now just avoids breaking changes later 👍🏻
… returned undefined Allow for passing operation to serializer
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #1748 +/- ##
=======================================
Coverage 91.44% 91.45%
=======================================
Files 144 144
Lines 7400 7406 +6
Branches 1481 1483 +2
=======================================
+ Hits 6767 6773 +6
Misses 633 633
|
I think I have addressed all the feedback, ready for another round 👍🏻 |
Which problem is this PR solving?
DynamoDB spans include the
db.statement
span attribute which can include un-sanitised sensitive data.Short description of the changes
Remove the
db.statement
attribute from DynamoDB spans due to not being sanitised of sensitive data.According to the semantic conventions spec:
I have updated the tests to explicitly assert that
db.statement
remains undefined.Contributes to #1552