@bucketsoffun
Welcome to Apache NiFi.
NiFi's Site-To-Site capability has been around since the very early stages of Apache NiFi. While the functionality has not changed, the world of security has evolved around it.
Prior to the release of Apache NiFi 1.14, the out-of-the-box installation was unsecured over HTTP. Securing NiFi required user configuration changes. 1.14+ out-of-the-box Apache NiFi start secured over HTTPS with generic certificates with the intent of being used only for evaluation purposes. Out-of-the box uses the following Security providers:
- single-user-provider --> Provides a single username and password only for authentication with only this NiFi instance. Dos not support additional local users. Does not support NiFi clusters.
- Single-user-authorizer --> Authorizes the single-user-provider user for complete authorized access to NiFi. Does not allow setting up additional authorizations.
This information will help understand the challenges you are having with using Sit-to-Site if you are using these out of the box security providers.
The Site-To-Site basics:
- The Remote Process Group (RPG) is always the client in the client to server connection, It always establishes the connection with the server side.
- The "remote" input/output ports are always the server side in the client to server connection. The client will either pull FlowFiles from a remote output port or push FlowFiles to remote input port.
Using localhost in the not going to work configured in the nifi.remote.input.host unless the only target you want the RPG to be able to talk to is itself (same server/host).
The RPG added to the canvas of your NiFi A:
- Configured with a URL for NiFi B (https://<nifi B hostname>:<nifi.web.https.port>/nifi)
- If configured with transport Protocol "RAW", will transmit FlowFiles or receive FlowFiles via the nifi.remote.input.socket.port configured on NiFi B
- If configured with transport protocol "HTTP", will transmit FlowFiles or receive FlowFiles via the nifi.web.https.port on NiFi B.
Once you "Apply" the RPG configuration, a background Site0To-Site thread executes periodically to fetch the Site-To-SIte details from the target URL (NiFi B). Those Site-To-Site details include details about that target NiFi (is it clustered or standalone, hostnames of all the cluster nodes, http/https ports for all cluster instances, all cluster node remote socket ports, load on each node in the target NiFi cluster, list of remote input and output ports that this client is authorized to use, etc). This information is then used for the actual connection and FlowFile transfer.
Authorization becomes the first challenge. Since the RPGs initial connection regardless of RAW or HTTP transport protocol configuration is always to the NiFi UIs hostname and port. When that is HTTPS that will require negotiating a successful mutualTLS exchange/handshake. The Client (RPG) will present the clientAuth certificate from the keystore configured in the nifi.properties file. The DN from that certificate is used as the user identity. That identity is then used check if the client has been authorized to "receive site-to-site details". This is what authorizes the RPG to get all the S2S details I mentioned earlier. The Remote Input ports and remote output ports also have client authorizations needed for the client (input port --> "receive data via site-to-site" and output port --> "send data via site-to-site").
So using the default security providers makes setting up the authorizations needed for site-to-site not possible between different hosts. So you should first experiment with setting up security using some other form of authentication and authorization.
Another option could be to unsecure your NiFi. This remove any need for authentication and authorization. You could then use the IP addresses assigned to your NiFi A and NiFi B in all the hostname configurations.
There are a lot moving parts here important to Site-To-Site between hosts.
I know this does not give you a step 1 to n process to get what you have working, but hopefully gets you high level communications negotiations that happen. Same exist when unsecured just without the authentication and authorization complexity.
I'd encourage you to explore the production ready authorization providers first so you have better understanding of the granular nature of NiFi authorizations.
If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped.
Thank you,
Matt
