Kafka was originally developed at LinkedIn in 2010. It was originally an open system to encourage adoption; developers could easily create new data streams, add data to the pipeline, and read data as it was created. It succeeded brilliantly at encouraging developers to build new data applications, improved the reliability of systems and applications, and helped LinkedIn scale it’s logging and data infrastructure.
Unfortunately, as Kafka usage grew at LinkedIn (and at other sites), we discovered problems with a totally open system. Developers might inadvertently cause production problems when creating new Kafka streams, engineers might change the configuration of critical systems, and employees might get access to sensitive data. As Kafka has been adopted by larger enterprises with more complex security requirements, we have had to rethink our architecture.
In this talk, we will explain how we have secured Apache Kafka. We will explain the threats that Kafka Security mitigates, the changes that we made to Kafka to enable security, and the steps required to secure an existing Kafka cluster.