First draft #1
First draft #1
Conversation
README.md
Outdated
| This repository is used for development of a proxy for at-rest encryption of Kafka topics as described in the [Strimzi proposal #17](https://github.com/strimzi/proposals/blob/master/017-kafka-topic-encryption.md). | ||
| The goal of this project, currently under development, is to provide topic-level encryption-at-rest for Kafka. | ||
|
|
||
| We all know the many strengths of [Apache Kafka](https://kafka.apache.org/) but one thing it does not directly support is encryption-at-rest for data stored by a broker. Yet Kafka is increasingly used as a store of data, not just as a means of transferring data from one location to another. This means that Kafka must conform to the same security and compliance requirements as conventional data storage systems such as relational databases. To compensate, Kafka service providers often use disk or file system encryption. This approach provides a degree of risk mitigation but also has well-known shortcomings, most notably the ability of anyone with appropriate file system permissions, such as system administrators, to read data. Security best practices and compliance standards therefore explicitly call for application- or database-level encryption to protect sensitive information against such exposures. Further, there should be a separation of duty between key management and system administration. |
There was a problem hiding this comment.
Bit folksy for my taste
There was a problem hiding this comment.
i.e. the "We all know ..."
There was a problem hiding this comment.
I was trying to spin it for a broad audience, less terse. I realized I was going out on a limb :)
OK, I will tone it down a bit.
| One core component, the _Encryption Module_, provides the encryption functionality. A second core component, the _Proxy_, intercepts Kafka connections and delegates message processing to the Encryption Module. | ||
|
|
||
| If so defined in the encryption policy, each topic can be encrypted by a different key, allowing brokers to store a mix of encrypted and unencrypted data, with data owners managing the keys to their topics. Keys will be stored in an external key management system with access policies and logging. | ||
|
|
There was a problem hiding this comment.
While initially we will use the proxy only for an introducing per-topic encrpytion, we will design it such other capabilities can be added there ...
There was a problem hiding this comment.
I can add that but am a bit skeptical: Generalizing the proxy has been speculative and more of a gentleman's agreement. Explicitly stating it as a goal puts us on the hook. Also a general proxy distracts from the "mission" of topic encryption.
I will add it in we can have another discussion about it.
There was a problem hiding this comment.
There is a danger, that we attract more attention than we want.
|
|
||
| P.S. The original [Strimzi proposal #17](https://github.com/strimzi/proposals/blob/master/017-kafka-topic-encryption.md) provides additional background. | ||
|
|
||
|
|
There was a problem hiding this comment.
Maybe something like:
"What is is in scope:
- ...
What is not in scope:
- ..."
|
Having slept on it, enumerating what is in scope, and what not, seems more appropriate for the forthcoming specification. Also suggesting how the proxy will be designed falls into the same category for me. Best suited for the requirements part of a specification. I question whether we want a generalizable proxy to be in scope. |
No description provided.