-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Use string map instead of opaque struct for dynamic metadata #2014
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Please add:
if entries is still empty after the loop, remove the key.
I like to have a option for filters not to dump data to mixer. Or another way, if filters want to dump data to mixer, they have to say so. We should not blindly dump everything to mixer. I have concern about performance, and security
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.
This is only in the report path. Dynamic metadata is strictly for logging.
See envoyproxy/envoy@700b7d0
In other words, even in Envoy, all dynamic metadata is already dumped on the wire, as is, just like static metadata. If filters store sensitive information, then there are bigger concerns including access logs, header values, etc. which are also being sent to mixer. So, lets have a separate discussion for that.
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 agree with Shriram on the security front, I'm not concerned.
I do wonder about the end-to-end perf impact. Can we measure the cost on proxy and Mixer CPU usage?
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.
No matter what we do, there is no way to tell other external filters that they need to log things for Istio mixer. Second, dynamic metadata is not 1000s of kbs of data. Its very very small bits of info like name of resource, or some key claim type, etc. This is the only way the mixer has, if it wishes to be able to log info about other OSS codecs like mongo/redis/kafka in Envoy. Otherwise, we will still be stuck with opaque TCP attributes like bytes sent, received, etc., while people prefer to turn off mixer and use envoy gRPC access logging to get richer metrics. :)
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.
@geeknoid It is hard to measure the performance without specify the metadata size. By design, dynamicMetadata is used for passing data in between filters. Authors may not realize its size has implication on the Mixer performance.
Sending over to mixer is different with logging. logging is for debugging, you may want to dump everything.
But sending to mixer is different, you don't want to dump everything
I strongly favor that if filters want their metadata to be send to mixer, they have to say so. It can be:
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.
???
Access log is most certainly not debugging. In fact, this PR came from Google: envoyproxy/envoy@700b7d0 and this is adding dynamic metadata to access logs streamed over gRPC.
Remember, I can always choose to overload the mixer by sending very very large HTTP headers, auth keys, etc. or several 100s of headers. So, the argument about performance is moot. We can potentially agree on some common prefix but that requires discussion with envoy folks as well, things like mongo/redis that generate dynamic metadata need to be modified to use this agreed upon prefix. This will take time. Do I have to be wait until then?
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.
Access log is not for debugging, error log is. All dynamic data are now streamed over gRPC if you configure Envoy to use gRPC access logger, the security concern is there but not addressed yet.
Dumping all dynamic metadata to attributes is not that bad, it is already done today just as protobuf serialized string. As an enhancement, we may do allow-list or deny-list of the metadata key as a follow up if we want more control on that.