You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Data Prepper's kafka buffer supports encryption. But, this feature is isolated only to this buffer. Other situations may warrant client-side encryption such as reading or writing to S3.
Additionally, the current solution somewhat combines two different encryption providers. We should make use of the AWS Encryption SDK for Java in the implementation.
Describe the solution you'd like
Data Prepper could provide an extension which supports client-side encryption. This approach would allow for the extensions to be pluggable so that different encryption providers could be available for use by different pipeline components.
Take the example of using KMS encryption in the Kafka buffer. Right now you need a configuration like the following.
In this situation we are stating that it will use the default encryption provider. We could also have named encryption providers to allow different topics to use different ones.
class EncryptionEnvelope {
/**
* The raw data such as the Data Prepper Event.
*/
String getData();
/**
* The envelope encryption key. It must be encrypted.
*/
String getEncryptedDataKey()
}
The existing EncryptionSerializer will need some additional design and refactoring. This is because it assumes a single data key.
Describe alternatives you've considered (Optional)
There are some alternative ways to express the data-prepper-config.yaml, but I chose the one I did because it looks most like the AWS plugin feature for named credentials.
Additional context
This would modify some of the behavior from #3486.
I'm following the convention of named AWS credentials as defined in #2570.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Data Prepper's
kafka
buffer supports encryption. But, this feature is isolated only to this buffer. Other situations may warrant client-side encryption such as reading or writing to S3.Additionally, the current solution somewhat combines two different encryption providers. We should make use of the AWS Encryption SDK for Java in the implementation.
Describe the solution you'd like
Data Prepper could provide an extension which supports client-side encryption. This approach would allow for the extensions to be pluggable so that different encryption providers could be available for use by different pipeline components.
Take the example of using KMS encryption in the Kafka buffer. Right now you need a configuration like the following.
This provides an encrypted data key (
encryption_key
) and KMS information for decrypting this encryption key.This could instead become.
In this situation we are stating that it will use the default encryption provider. We could also have named encryption providers to allow different topics to use different ones.
To support this, we will allow configuring this encryption in the
data-prepper-config.yaml
file.It could also support named configurations:
Data Prepper would provide a new interface for encryption.
The existing
EncryptionSerializer
will need some additional design and refactoring. This is because it assumes a single data key.Describe alternatives you've considered (Optional)
There are some alternative ways to express the
data-prepper-config.yaml
, but I chose the one I did because it looks most like the AWS plugin feature for named credentials.Additional context
This would modify some of the behavior from #3486.
I'm following the convention of named AWS credentials as defined in #2570.
The text was updated successfully, but these errors were encountered: