Can nifi cluster which enabled SSL be scaled without reboot in kubernetes

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Can nifi cluster which enabled SSL be scaled without reboot in kubernetes

笑对人生
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
Reply | Threaded
Open this post in threaded view
|

Re: Can nifi cluster which enabled SSL be scaled without reboot in kubernetes

Peter Wilcsinszky
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 笑对人生 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Can nifi cluster which enabled SSL be scaled without reboot in kubernetes

Andy LoPresto-2
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
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Sep 23, 2018, at 6:44 AM, Peter Wilcsinszky <[hidden email]> 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 笑对人生 <[hidden email]> 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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Can nifi cluster which enabled SSL be scaled without reboot in kubernetes

Peter Wilcsinszky
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 <[hidden email]> 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
> [hidden email]
> *[hidden email] <[hidden email]>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Sep 23, 2018, at 6:44 AM, Peter Wilcsinszky <[hidden email]>
> 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 笑对人生 <[hidden email]> 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
>
>
>