There can be several consumers which can read data from the Kafka and producers which can produce data. But, it is also necessary to ensure the security of data.
Need for Kafka Security
There are certain reasons which describe the need for security:
Components of Kafka Security
Mainly, there are three major components of Kafka Security:
Following are the security models used in Apache Kafka:
The different SASL mechanisms are:
GSSAPI(Kerberos): If Kerberos server or Active Directory is already in use, there is no requirement to install a new server only for Kafka.
PLAIN: It is a simple traditional security approach that uses a valid username and password for the authentication mechanism. In Kafka, PLAIN is the default implementation. It can be further extended for production use in Kafka. SASL/PLAIN should be used as a transport layer for ensuring that clear passwords are not transmitted over the wire without encrypting it.
SCRAM: It extends for the ?Salted Challenge Response Authentication Mechanism?. It is a family of SASL mechanism which addresses the security concerns by performing username/password authentication such as PLAIN does. The SCRAM in Kafka keeps its credentials in the zookeeper, which can be further used for Kafka installations.
OUATHBEARER: The OUATH2 Authorization Framework allows a third party application for accessing HTTP service in a limit. The default OAUTHBEARER in Kafka is suitable for use in non-production installations of Apache Kafka. Also, it creates as well as validates Unsecured JSON web tokens.
Delegation Tokens: It is a lightweight authentication mechanism used for completing the SASL/SSL methods. Delegation tokens work as a shared secret between Kafka brokers and clients. These tokens help frameworks in distributing the workload to the available workers in a secure environment. Also, no additional distribution cost is required.
Thus, through encryption, authentication as well as authorization, one can enable the Kafka security for the data.