What's new in this release?

Cloudera Flow Management (CFM) 2.1.1 is a major release of CFM on CDP Private Cloud Base. It is the first version based on Apache NiFi 1.13.2. In addition, CFM 2.1.1 also includes bug fixes and improvements on top of the Apache NiFi release.

CDP Private Cloud Base support

CFM 2.1.1 supports CDP Private Cloud Base 7.1.6.

If you are upgrading to CFM 2.1.1, see CFM upgrade and migration paths.

SAML authentication
NiFi now supports user authentication through a Security Assertion Markup Language (SAML).

For more information, see SAML Authentication.

Restricted-component policy is more granular
Fine-tune access by a restricted component to the localhost filesystem data by specifying the restricted component and type of permission in the policy that you assign to the user or user group. This also makes a distinction between processors that can access the local filesystem where NiFi is running and the processors that can access a distributed file system like the Hadoop related processors.

For more information, see NiFi Restricted Components.

Ability to install NiFi clusters with Ranger/Solr but no HDFS
Starting with CFM 2.1.1 and CDP 7.1.6, you can now deploy NiFi clusters that use Ranger for authorization, but do not require HDFS. If you are a legacy Hortonworks customer and have NiFi from HDF with Ranger but did not install HDFS to store audit logs with Ranger, you now have two options:
  • Use HDFS for long-term audit log archive and Solr for indexing and searching
  • Keep using only Solr as in HDFS
FIPS compliance
You can encrypt NiFi sensitive properties with a secret key generated by the FIPS 140-2 approved PBKDF2 algorithm. For more information, see FIPS 140-2 Compliance.
NiFi-Ozone integration
If Ozone is installed in your CDP cluster, you can use the HDFS processors in NiFi to interact with the Ozone storage layer.
NiFi node status history and status repository
Starting with CFM 2.1.1, it is now possible to access a Node Status History view from the hamburger menu. This provides useful monitoring data about the NiFi nodes in the cluster over time. Just like Status History data at the component level, Node History data is stored in memory by default and removed after a NiFi restart.
It is now possible to persist both Node and Status history data by setting the nifi.components.status.repository.implementation property in the nifi.properties file.

For more information, see the Status History Repository topic in the Apache NiFi Administration Guide.