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

Write encryption data to the Kafka protobuf messages #3976

Conversation

dlvenable
Copy link
Member

@dlvenable dlvenable commented Jan 18, 2024

Description

When writing Kafka buffer events, save additional information about the encryption in the protobuf record.

This adds two new fields to the Protobuf message:

  • encrypted
  • encrypted_data_key

This work does not include using that data when reading. I plan to do that in a follow-on PR, but want to keep the PRs from getting too large.

Issues Resolved

Contributes toward #3655.

Check List

  • New functionality includes testing.
  • New functionality has a documentation issue. Please link to it in this PR.
    • New functionality has javadoc added
  • Commits are signed with a real name per the DCO

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

…he encryption in the protobuf record. Contributes toward opensearch-project#3655.

Signed-off-by: David Venable <[email protected]>
@@ -16,4 +16,13 @@ message BufferData {
* is unencrypted data.
*/
bytes data = 2;

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think this structure have version field to support changes like this for backward compatibility.

Copy link
Member Author

Choose a reason for hiding this comment

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

Are you proposing an optional string version = 3; that we'd use to track versions of this? What would the values of these be?

I gather that protobuf messages do not need a version string. Typically developers handle this by keeping backward compatibility.

If we add a version, would it be something as simple as 1? And then we change to 2 if we ever do choose to make a breaking change?

Copy link
Collaborator

Choose a reason for hiding this comment

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

it should be mandatory and should change whenever the definition of the protobuf message structure changes. This PR is changing the existing structure to a new structure. What happens if writer (producer) to kafka writes one version and the reader of kafka is a different dataprepper version with modified structure?

Copy link
Member Author

Choose a reason for hiding this comment

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

Protobuf has built-in support for this. A Data Prepper running with this structure will be ok with the old data because it is marked as optional.

https://protobuf.dev/programming-guides/proto3/#updating

Copy link
Collaborator

Choose a reason for hiding this comment

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

I see. How does this code handle if the protobuf message doesn't have the new fields? I understand the protobuf libraries handle it gracefully, don't the code need to handle it as well?

Copy link
Member Author

Choose a reason for hiding this comment

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

Right now this code is only adding the new messages as noted in the description. I will have a follow-on PR that will use the fields (if provided) to decrypt the data. If not provided, then we will attempt to decrypt with the current key.

Copy link
Contributor

@JonahCalvo JonahCalvo left a comment

Choose a reason for hiding this comment

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

LGTM

@dlvenable dlvenable merged commit c45ddb1 into opensearch-project:main Feb 8, 2024
48 of 50 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants