https://kafka.apache.org/43/security/Recent content in Security on Apache KafkaHugo -- gohugo.ioenhttps://kafka.apache.org/43/security/security-overview/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/43/security/security-overview/The following security measures are currently supported: Authentication of connections to brokers from clients (producers and consumers), other brokers and tools, using either SSL or SASL. Kafka supports the following SASL mechanisms: SASL/GSSAPI (Kerberos) - starting at version 0.9.0.0 SASL/PLAIN - starting at version 0.10.0.0 SASL/SCRAM-SHA-256 and SASL/SCRAM-SHA-512 - starting at version 0.10.2.0 SASL/OAUTHBEARER - starting at version 2.0 Encryption of data transferred between brokers and clients, between brokers, or between brokers and tools using SSL (Note that there is a performance degradation when SSL is enabled, the magnitude of which depends on the CPU type and the JVM implementation.https://kafka.apache.org/43/security/listener-configuration/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/43/security/listener-configuration/In order to secure a Kafka cluster, it is necessary to secure the channels that are used to communicate with the servers. Each server must define the set of listeners that are used to receive requests from clients as well as other servers. Each listener may be configured to authenticate clients using various mechanisms and to ensure traffic between the server and the client is encrypted. This section provides a primer for the configuration of listeners.https://kafka.apache.org/43/security/encryption-and-authentication-using-ssl/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/43/security/encryption-and-authentication-using-ssl/Apache Kafka allows clients to use SSL for encryption of traffic as well as authentication. By default, SSL is disabled but can be turned on if needed. The following paragraphs explain in detail how to set up your own PKI infrastructure, use it to create certificates and configure Kafka to use these. Generate SSL key and certificate for each Kafka broker The first step of deploying one or more brokers with SSL support is to generate a public/private keypair for every server.https://kafka.apache.org/43/security/authentication-using-sasl/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/43/security/authentication-using-sasl/JAAS configuration Kafka uses the Java Authentication and Authorization Service (JAAS) for SASL configuration. JAAS configuration for Kafka brokers KafkaServer is the section name in the JAAS file used by each KafkaServer/Broker. This section provides SASL configuration options for the broker including any SASL client connections made by the broker for inter-broker communication. If multiple listeners are configured to use SASL, the section name may be prefixed with the listener name in lower-case followed by a period, e.https://kafka.apache.org/43/security/authorization-and-acls/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/43/security/authorization-and-acls/Kafka ships with a pluggable authorization framework, which is configured with the authorizer.class.name property in the server configuration. Configured implementations must extend org.apache.kafka.server.authorizer.Authorizer. Kafka provides a default implementation which store ACLs in the cluster metadata (KRaft metadata log). For KRaft clusters, use the following configuration on all nodes (brokers, controllers, or combined broker/controller nodes): authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer Kafka ACLs are defined in the general format of “Principal {P} is [Allowed|Denied] Operation {O} From Host {H} on any Resource {R} matching ResourcePattern {RP}”.https://kafka.apache.org/43/security/incorporating-security-features-in-a-running-cluster/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/43/security/incorporating-security-features-in-a-running-cluster/You can secure a running cluster via one or more of the supported protocols discussed previously. This is done in phases: Incrementally bounce the cluster nodes to open additional secured port(s). Restart clients using the secured rather than PLAINTEXT port (assuming you are securing the client-broker connection). Incrementally bounce the cluster again to enable broker-to-broker security (if this is required) A final incremental bounce to close the PLAINTEXT port. The specific steps for configuring SSL and SASL are described in sections 7.