PublishKafka2CDP 2.3.0.4.10.0.0-147

Bundle
com.cloudera | nifi-cdf-kafka-2-nar
Description
Sends the contents of a FlowFile as a message to Apache Kafka using the Kafka 2.5.0.7.1.7.1000-141 Producer API.The messages to send may be individual FlowFiles or may be delimited, using a user-specified delimiter, such as a new-line. The complementary NiFi processor for fetching messages is ConsumeKafka2CDP.
Tags
2.5.0.7.1.7.1000-141, Apache, Kafka, Message, PubSub, Put, Send
Input Requirement
REQUIRED
Supports Sensitive Dynamic Properties
false
  • Additional Details for PublishKafka2CDP 2.3.0.4.10.0.0-147

    PublishKafka2CDP

    Description

    This Processor puts the contents of a FlowFile to a Topic in Apache Kafka using KafkaProducer API available with Kafka CLOUDERA_KAFKA_VERSION API. The content of a FlowFile becomes the contents of a Kafka message. This message is optionally assigned a key by using the <Kafka Key> Property.

    The Processor allows the user to configure an optional Message Demarcator that can be used to send many messages per FlowFile. For example, a \n could be used to indicate that the contents of the FlowFile should be used to send one message per line of text. It also supports multi-char demarcators (e.g., ‘my custom demarcator’). If the property is not set, the entire contents of the FlowFile will be sent as a single message. When using the demarcator, if some messages are successfully sent but other messages fail to send, the resulting FlowFile will be considered a failed FlowFile and will have additional attributes to that effect. One of such attributes is ‘failed.last.idx’ which indicates the index of the last message that was successfully ACKed by Kafka. (if no demarcator is used the value of this index will be -1). This will allow PublishKafka to only re-send un-ACKed messages on the next re-try.

    Security Configuration

    The Security Protocol property allows the user to specify the protocol for communicating with the Kafka broker. The following sections describe each of the protocols in further detail.

    PLAINTEXT

    This option provides an unsecured connection to the broker, with no client authentication and no encryption. In order to use this option the broker must be configured with a listener of the form:

    
    PLAINTEXT://host.name:port

    SSL

    This option provides an encrypted connection to the broker, with optional client authentication. In order to use this option the broker must be configured with a listener of the form:

    
    SSL://host.name:port

    In addition, the processor must have an SSL Context Service selected.

    If the broker specifies ssl.client.auth=none, or does not specify ssl.client.auth, then the client will not be required to present a certificate. In this case, the SSL Context Service selected may specify only a truststore containing the public key of the certificate authority used to sign the broker’s key.

    If the broker specifies ssl.client.auth=required then the client will be required to present a certificate. In this case, the SSL Context Service must also specify a keystore containing a client key, in addition to a truststore as described above.

    SASL_PLAINTEXT

    This option uses SASL with a PLAINTEXT transport layer to authenticate to the broker. In order to use this option the broker must be configured with a listener of the form:

    
    SASL_PLAINTEXT://host.name:port

    In addition, the Kerberos Service Name must be specified in the processor.

    SASL_PLAINTEXT - GSSAPI

    If the SASL mechanism is GSSAPI, then the client must provide a JAAS configuration to authenticate. The JAAS configuration can be provided by specifying the java.security.auth.login.config system property in NiFi’s bootstrap.conf, such as:

    
    java.arg.16=-Djava.security.auth.login.config=/path/to/kafka_client_jaas.conf

    An example of the JAAS config file would be the following:

    
    KafkaClient {
        com.sun.security.auth.module.Krb5LoginModule required
        useKeyTab=true
        storeKey=true
        keyTab="/path/to/nifi.keytab"
        serviceName="kafka"
        principal="nifi@YOURREALM.COM";
    };

    NOTE: The serviceName in the JAAS file must match the Kerberos Service Name in the processor.

    Alternatively, the JAAS configuration when using GSSAPI can be provided by specifying the Kerberos Principal and Kerberos Keytab directly in the processor properties. This will dynamically create a JAAS configuration like above, and will take precedence over the java.security.auth.login.config system property.

    SASL_PLAINTEXT - PLAIN

    If the SASL mechanism is PLAIN, then client must provide a JAAS configuration to authenticate, but the JAAS configuration must use Kafka’s PlainLoginModule. An example of the JAAS config file would be the following:

    
    KafkaClient {
      org.apache.kafka.common.security.plain.PlainLoginModule required
      username="nifi"
      password="nifi-password";
    };

    The JAAS configuration can be provided by either of below ways

    1. specify the java.security.auth.login.config system property in NiFi’s bootstrap.conf. This limits you to use only one user credential across the cluster.
    
                java.arg.16=-Djava.security.auth.login.config=/path/to/kafka_client_jaas.conf
    1. add user attribute ‘sasl.jaas.config’ in the processor configurations. This method allows one to have multiple consumers with different user credentials or gives flexibility to consume from multiple kafka clusters.
    
                sasl.jaas.config : org.apache.kafka.common.security.plain.PlainLoginModule required
                                        username="nifi"
                                        password="nifi-password";

    NOTE: The dynamic properties of this processor are not secured and as a result the password entered when utilizing sasl.jaas.config will be stored in the flow.xml.gz file in plain-text, and will be saved to NiFi Registry if using versioned flows.

    NOTE: It is not recommended to use a SASL mechanism of PLAIN with SASL_PLAINTEXT, as it would transmit the username and password unencrypted.

    NOTE: The Kerberos Service Name is not required for SASL mechanism of PLAIN. However, processor warns saying this attribute has to be filled with non empty string. You can choose to fill any random string, such as “null”.

    NOTE: Using the PlainLoginModule will cause it be registered in the JVM’s static list of Providers, making it visible to components in other NARs that may access the providers. There is currently a known issue where Kafka processors using the PlainLoginModule will cause HDFS processors with Keberos to no longer work.

    SASL_PLAINTEXT - SCRAM

    If the SASL mechanism is SSL, then client must provide a JAAS configuration to authenticate, but the JAAS configuration must use Kafka’s ScramLoginModule. Ensure that you add user defined attribute ‘sasl.mechanism’ and assign ‘SCRAM-SHA-256’ or ‘SCRAM-SHA-512’ based on kafka broker configurations. An example of the JAAS config file would be the following:

    
    KafkaClient {
      org.apache.kafka.common.security.scram.ScramLoginModule
      username="nifi"
      password="nifi-password";
    };

    The JAAS configuration can be provided by either of below ways

    1. specify the java.security.auth.login.config system property in NiFi’s bootstrap.conf. This limits you to use only one user credential across the cluster.
    
                java.arg.16=-Djava.security.auth.login.config=/path/to/kafka_client_jaas.conf
    1. add user attribute ‘sasl.jaas.config’ in the processor configurations. This method allows one to have multiple consumers with different user credentials or gives flexibility to consume from multiple kafka clusters.
    
                sasl.jaas.config : org.apache.kafka.common.security.scram.ScramLoginModule required
                                        username="nifi"
                                        password="nifi-password";

    NOTE: The dynamic properties of this processor are not secured and as a result the password entered when utilizing sasl.jaas.config will be stored in the flow.xml.gz file in plain-text, and will be saved to NiFi Registry if using versioned flows.

    NOTE: The Kerberos Service Name is not required for SASL mechanism of SCRAM-SHA-256 or SCRAM-SHA-512. However, processor warns saying this attribute has to be filled with non empty string. You can choose to fill any random string, such as “null”.

    SASL_SSL

    This option uses SASL with an SSL/TLS transport layer to authenticate to the broker. In order to use this option the broker must be configured with a listener of the form:

    
    SASL_SSL://host.name:port

    See the SASL_PLAINTEXT section for a description of how to provide the proper JAAS configuration depending on the SASL mechanism (GSSAPI or PLAIN).

    See the SSL section for a description of how to configure the SSL Context Service based on the ssl.client.auth property.

Properties
Dynamic Properties
Relationships
Name Description
success FlowFiles for which all content was sent to Kafka.
failure Any FlowFile that cannot be sent to Kafka will be routed to this Relationship
Reads Attributes
Name Description
kafka.tombstone If this attribute is set to 'true', if the processor is not configured with a demarcator and if the FlowFile's content is null, then a tombstone message with zero bytes will be sent to Kafka.
Writes Attributes
Name Description
msg.count The number of messages that were sent to Kafka for this FlowFile. This attribute is added only to FlowFiles that are routed to success. If the <Message Demarcator> Property is not set, this will always be 1, but if the Property is set, it may be greater than 1.