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.
