Andy, For the pre-shared key - to avoid having to provide another sensitive value through the config - maybe we could have a set of short lived keys generated by the cluster nodes on the admin's request. It could be available on the UI or through the CLI from the existing nodes.
One more thing I can think of for dynamic authentication is to have a dedicated CA for the nodes only. For dynamic authorization my idea is to build on the "Node Group" feature [1]. With this we still need to have a UserGroupProvider to provide us with nodes and groups dynamically for example by talking to the API of the provisioner system that adds and removes nodes. [1] https://issues.apache.org/jira/browse/NIFI-5542 On Mon, Sep 24, 2018 at 12:53 AM Andy LoPresto <[email protected]> wrote: > Peter, > > Can you think of a good way to script the following actions when the new > node comes online? > > * Request certificate be issued to new node from CA > * Use certificate to perform REST API request to an existing node to add > the new node as an authorized user and grant it R/W for /proxy > > I believe the blocker right now would be the new node *isn’t* an > authorized user, so it can’t add itself as a new user. With a wildcard > certificate this could work, but wildcard certificates cause a lot of other > problems, and adding explicit users wouldn’t be necessary in that case. > > We could possibly introduce a new feature where nodes could be added with > a pre-shared key (i.e. a custom password configured in the nifi.properties > file of the nodes that start the cluster), or any new node with a > certificate signed by the CA could join automatically if that setting is > turned on (would default false for scenarios where non-authorized users > would also have certificates signed by the same CA). > > Andy LoPresto > [email protected] > *[email protected] <[email protected]>* > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Sep 23, 2018, at 6:44 AM, Peter Wilcsinszky <[email protected]> > wrote: > > Hi Fugui! > > There is no need to restart the nodes. You should use a properly filled > authorizers.xml for the initial cluster nodes only. Then as you add new > nodes you should use an authorizers.xml that is "empty" meaning it has no > nodes and users in it, neither the initial admin defined in the policy and > user providers. If you do this the node will inherit authorizations > configuration from the existing nodes. The trick is, that then you have to > add the new node on the UI manually and grant read/write proxy permissions > for it as well. > > Peter > > On Sun, Sep 23, 2018 at 5:23 AM 笑对人生 <[email protected]> wrote: > > Hi , > I've encountered some problems when I deploy a secure nifi cluster in > Kubernetes,. Could you help me analyze my problems? > Can nifi cluster which enabled SSL be scaled without reboot in > kubernetes? > When I add a new node to a secure nifi cluster in kubernetes, do I need > to modify the authorizers.xml file for each node? > Whether each node needs to maintain a mapping of host name and domain > name in /etc/hosts file? > https://github.com/AlexsJones/kubernetes-nifi-cluster/issues/2 How can > this problem be solved? > Look forward to your reply! Thank you for your time. > Regards, > Fugui > > >
