...
- Migrating from 1.13.x to 1.14.0 (unreleased)
- NiFi is now secure by default. The default port has been changed from 8080 to 8443 and a certificate is automatically generated. Upon the first start, unless the configuration is changed, a username and password will be automatically generated and written to the logs. The username and password may be changed at any time by running bin/nifi.sh set-single-user-credentials <username> <password>
- The sensitive properties key is no longer set by default. Previously, a default value of "nififtw!" but that mean that if the default was never changed, anyone who gained access to the flow.xml.gz (whether maliciously or not) could decrypt sensitive properties. Now, the value must be explicitly set. Otherwise, NiFi will fail to startupif no value is set, one will be randomly generated upon NiFI start, and it will be written to nifi.properties. The value can be set by running `bin/nifi.sh set-sensitive-properties-key <new key>`. This will automatically lookup the current sensitive properties key from nifi.properties (and use the default nififtw! if the property is not set), decrypt any sensitive keys, re-encrypt with the new key, and write all of the configuration with the newly encrypted values. This can be used to set the initial password or to change an existing password. It is important to note that if the sensitive properties key is lost, NiFi will not be able to load the flow.xml.gz and will fail upon startup. If this occurs, manual intervention will be required in order to remove any sensitive properties from the flow.xml.gz, and those sensitive values must then be re-configured after starting NiFi. For this reason, it is highly recommend that a sensitive properties key be set explicitly.
- The nifi-storm-spout module was removed from nifi-external and will no longer be provided in source or binary form. Users requiring the module can obtain the source and binary from 1.13.x and prior releases.
- Processors were never intended to be scheduled to run on Primary Node Only unless they were a "source" processor. Doing so can cause issues with data sitting in the flow and never being processed. But that rule was never enforced. Until now. In 1.14.0, any Processor that is scheduled to run on Primary Node Only and also has incoming connections will be made invalid. Please ensure that any Processor that receives data from another Processor is scheduled to run on All Nodes (this is set by going to the Processor Configuration and navigating to the Scheduling tab).
- Migrating from 1.13.x to 1.13.1
- Removed the following nar(s) from the convenience build. They are still built and made available in maven repositories so you can add them to your deployment lib folder and use them if you like. They include; nifi-grpc-nar
- Migrating from 1.12.x to 1.13.x
- HTTP access to NiFi by default is now configured to accept connections to 127.0.0.1/localhost only. If you want to allow broader access for some reason for HTTP and you understand the security implications you can still control that as always by changing the 'nifi.web.http.host' property in nifi.properties as always. That said, please take the time to configure proper HTTPS. We offer detailed instructions and tooling to assist.
- Removed the following nar(s) from the convenience build. They are still built and made available in maven repositories so you can add them to your deployment lib folder and use them if you like. They include; nifi-livy-nar, nifi-livy-controller-service-api-nar, nifi-kafka-0-11-nar, nifi-beats-nar, nifi-ignite-nar
- Both embedded and external ZooKeeper connections can now be secured with TLS. The administration guide contains configuration examples to enable this feature. For embedded ZooKeeper, it will require setting the secureClientPort value in zookeeper.properties. There are also new properties defined in the admin guide, including nifi.zookeeper.client.secure which tells NiFI to use a secure client to access a secured ZooKeeper, and nifi.zookeeper.security.* properties to define separate key/trust stores if required. By default the nifi.security.* values will be used to establish trust, but if nifi.zookeeper.security.* values are defined, these will be used instead.
- The handling of the X-ProxiedEntitiesChain header for secure proxied requests is now more strict, requiring the outermost <, >. For example, whereas a value of %{SSL_CLIENT_S_DN} (Apache httpd) or $ssl_client_s_dn (NGINX) was previously valid, <%{SSL_CLIENT_S_DN}> or <$ssl_client_s_dn> must now be used.
...