@zzzz77  Apache NiFi use to be by default unsecured when launched without setting up security manually.  The expectation was that the end user of Apache NiFi would take steps to secure the NiFi before using it for production use cases to protect sensitive data.  More recently the Apache Community decided to have NiFi Start securely out of the box. This was partly for two reasons.  First to avoid users from accidentally exposing sensitive information by have their NiFi running wide open to anyone who can access the url.  Secondly, most modern browser now force users to https://.... when an http://.. . address is supplied.   The out-of-the-box secure setup provides very minimal security.  It generates self-signed certificate so that TLS/SSL https can be used and it utilizes a new "Single User" authentication and "Single User Authorizer".     This single user authorizer give the generated single user full access to the NiFi.  There is no way to create additional users or modify authorizations when using this authorization provider.  It's intended use is to provide a secure NiFi out-of-the-box for ease of product evaluation.  For a more robust multi-user NiFi deployment different user authentication and Authorization provider need to be used.  Also recommend generating/obtaining properly signed certificates for your NiFi instance(s).   LDAP is probably the most commonly used for authentication through the "ldap-provider" since NiFi does not have a multi-user local provider option.  You can find  all authentication provider options in NiFi in teh admin guide under: User Authentication  With a change to the authentication provider, you will also need to setup a multi-user authorizer so you can manage the authorization for your ldap user identities.   You can find option in the admin guide under Multi-Tenant Authorization. Most common setup typically utilizes the Managed-Authorizer, File-Access-Policy-Provider, Composite-Configurable-User-Group-Provider, File-User-Group-Provider, and LDAP-User-Group-Provider. In your File-Access-Policy-Provider, you'll be able to define who your "initial admin" user will be.  This would typically be one of your ldap users.  This provider on first launch will generate a authorizations.xml file that will contain the minimum required authorization required for the admin user.  NOTE: the initial admin does not get access granted to everything; however, will have ability to granted all additional authorizations the admin user may want and to setup authorizations for all other users. The admin guide also covers the various authorization policies here: Configuring Users & Access Policies NiFi authorizations are very granular.  You can set unique policies for each user if you want.   EVERY user must be authorized for "view the user interface" or the user will not be able to access the UI.  The admin user can optionally create a different process group on the NiGi UI for each team or person that will be building dataflows on the canvas.  The Admin user then authorizes the team of person to the appropriate process group. This prevents one user/team form being able to view the configuration of another teams dataflow or modify another teams dataflows.  They will only have access within their authorized process group.   A user does not need to be an "Admin user" to build dataflows.   What makes a user an admin is someone who can modify all policies, modify users, etc.    Individual users can not modify authorizations or user and can still be granted ability to modify components so they can build dataflows within their admin authorized process group(s). NOTE: All user can see where all components are placed on canvas tp prevent one team from building on top of another; however, those components for which a user is not aithorized will appear with dashed outlines and no details. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more

Hello @zzzz77, Did the answers help you here?  If so, please consider marking the comment that help you as the solution.  ... View more

@hckorkmaz01  While you are currently still using Apache NiFi 1.x major release version, it has reached end of life and is no longer receiving contributions.  As such components will not get library updates or security fixes going forward.   Apache NiFi 2.x is currently active major release being contributed to in the community.  The PrometheusReportingTask was deprecated in Apache NiFi 1.x and officially removed in Apache NiFi 2.x major release.   So I would avoid using it as you will eventually need to move to Apache NiFi 2.x to maintain a secure supported product release.  But technically, this reporting task, while not well maintained in the community, is capable of creating a prometheus endpoint which exposes metrics for all components (includes connections) for consumption. That being said, Cloudera has taken steps to create Cloudera versions of many of the deprecated and removed components in Apache NiFi 2.x; as well as, introduced many components not available at all in any Apache release version (PrometheusReportingTask is not one of them that was retained). https://docs.cloudera.com/cfm/4.11.0/nifi-components-cfm/components/ NOTE:  You are already using a considerably older Apache NiFI 1.18 release.  Many bug fixes and CVEs security issues have been addressed since that release.  If you cannot yet move to Apache NiFi 2.x, you should at least be on the most recent release of Apache NIFi 1.28. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more