Yolanda M. Davis created NIFI-4022:
--------------------------------------
Summary: Use SASL Auth Scheme For Secured Zookeeper Client
Interaction
Key: NIFI-4022
URL: https://issues.apache.org/jira/browse/NIFI-4022
Project: Apache NiFi
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Yolanda M. Davis
NiFi uses Zookeeper to assist in cluster orchestration including leader
elections for Primary Node and Cluster Coordinator and to store state for
various processors (such as MonitorActivity). In secured Zookeeper environments
(supported by SASL + Kerberos) NiFi should protect the zNodes it creates to
prevent users or hosts, outside of a NiFi cluster, from accessing or modifying
entries. In its current implementation security can be enforced for processors
that store state information in Zookeeper, however zNodes used for managing
Primary Node and Cluster Coordinator data are left open and susceptible to
change from any user. Also when zNodes are secured for processor state, a
“Creator Only” policy is used which allows the system to determine the
identification of the NiFi node and protect any zNodes created with that node
id using Zookeeper’s “auth” scheme. The challenge with this scheme is that it
limits the ability for other NiFi nodes in the cluster to access that zNode if
needed (since it is specifically binds that zNode to the unique id of its
creator).
To best protect zNodes created in Zookeeper by NiFi while maximizing NiFi’s
ability to share information across the cluster I propose that we move to using
Zookeeper’s SASL authentication scheme, which will allow the use of Kerberos
principals for securing zNode with the appropriate permissions. For maximum
flexibility, these principals can be mapped appropriately in Zookeeper, using
auth-to-local rules, to ensure that nodes across the cluster can share zNodes
as needed.
Potential Concerns/Challenges for Discussion:
1) For existing NiFi users how will we migrate Zookeeper entries from the
old security scheme to the new scheme?
2) How should zNodes be reverted to open if kerberos is disabled?
3) What will the performance impact be on the cluster once SASL scheme is
enabled (since we’d be moving from open to protected)? Would require
investigation
4) Currently users can control authentication scheme via state management
configuration for processors yet not for clusters. Should we still maintain
the practice of allowing schemes to be configurable for processors (with SASL
being the new default)?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
