https://kafka.apache.org/44/security/Recent content in Security on Apache KafkaHugo -- gohugo.ioenhttps://kafka.apache.org/44/security/security-overview/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/44/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/44/security/listener-configuration/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/44/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/44/security/encryption-and-authentication-using-ssl/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/44/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/44/security/authentication-using-sasl/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/44/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/44/security/authorization-and-acls/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/44/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/44/security/incorporating-security-features-in-a-running-cluster/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/44/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.https://kafka.apache.org/44/security/security-model/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/44/security/security-model/Things You Need To Know Security is off by default. A freshly-installed Apache Kafka cluster accepts unauthenticated PLAINTEXT connections on every listener and applies no authorization. This is appropriate only for closed test environments. Production deployments must explicitly configure authentication, authorization, and transport encryption before being exposed to any untrusted network. Apache Kafka assumes a trusted operator. Anyone with shell access to a broker, controller, or the underlying disks can read every topic, forge any principal, and rewrite ACLs.https://kafka.apache.org/44/security/security-model-connect/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/44/security/security-model-connect/This page extends the Apache Kafka security model to Kafka Connect. A worker authenticates to the Kafka cluster over a configured SASL_SSL/SSL listener exactly like any other client, so everything the core model says about authentication, authorization, and transport encryption to the brokers applies unchanged. What follows covers only what Connect adds on top — chiefly its own control plane, the REST API, and the fact that it runs user-supplied code.https://kafka.apache.org/44/security/security-model-streams/Mon, 01 Jan 0001 00:00:00 +0000https://kafka.apache.org/44/security/security-model-streams/This page extends the Apache Kafka security model to Kafka Streams. From the cluster’s perspective a Streams application is an ordinary Kafka client and inherits the broker’s authentication, authorization, and transport-encryption model through the same ssl.* and sasl.* client configs. Things You Need To Know Streams is a client library, not a service. It runs inside your application’s process, so its security boundary is the application’s; there is no separate Streams network surface to secure.