[
https://issues.apache.org/jira/browse/NIFI-5752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16665201#comment-16665201
]
ASF GitHub Bot commented on NIFI-5752:
--------------------------------------
Github user markap14 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3110#discussion_r228534325
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/queue/clustered/server/ClusterLoadBalanceAuthorizer.java
---
@@ -40,28 +42,23 @@ public ClusterLoadBalanceAuthorizer(final
ClusterCoordinator clusterCoordinator,
}
@Override
- public void authorize(final Collection<String> clientIdentities)
throws NotAuthorizedException {
- if (clientIdentities == null) {
- logger.debug("Client Identities is null, so assuming that Load
Balancing communications are not secure. Authorizing client to participate in
Load Balancing");
- return;
- }
-
- final Set<String> nodeIds =
clusterCoordinator.getNodeIdentifiers().stream()
+ public void authorize(final SSLSession sslSession) throws
NotAuthorizedException {
+ final List<String> nodeIds =
clusterCoordinator.getNodeIdentifiers().stream()
.map(NodeIdentifier::getApiAddress)
- .collect(Collectors.toSet());
+ .collect(Collectors.toList());
- for (final String clientId : clientIdentities) {
- if (nodeIds.contains(clientId)) {
- logger.debug("Client ID '{}' is in the list of Nodes in
the Cluster. Authorizing Client to Load Balance data", clientId);
+ for (final String nodeId : nodeIds) {
+ final HostnameVerifier verifier = new
DefaultHostnameVerifier();
+ if (verifier.verify(nodeId, sslSession)) {
+ logger.debug("Authorizing Client to Load Balance data");
return;
--- End diff --
I think falling back to the hostname from the socket whenever there is not
an exact match (i.e., the wildcard matches but not an exact string comparison)
is fair. Originally, we used the hostname directly from the socket, but as Koji
mentioned in #3109 we changed that behavior. This was done because when you
look at Provenance data (and in logs), what you may see is something like a
RECEIVE event with a transit URI of nifi://s7302.r720.y8302.mydomain.com
because that's the FQDN but the user typically references this node as say
nifi-01.mydomain.com. If the UI shows the node as nifi-01.mydomain.com in the
cluster table, then it is best to show that in the Provenance and logs as well.
This is especially true in virtual environments, running in Docker or in a
publish Cloud/VM where often the hostname reported by socket.getInetAddress()
is very different than what we typically like to see.
Does that make sense?
Also @kotarot thank you for noticing this and submitting this contribution!
> Load balancing fails with wildcard certs
> ----------------------------------------
>
> Key: NIFI-5752
> URL: https://issues.apache.org/jira/browse/NIFI-5752
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.8.0
> Reporter: Kotaro Terada
> Assignee: Kotaro Terada
> Priority: Major
>
> Load balancing fails when we construct a secure cluster with wildcard certs.
> For example, assume that we have a valid wildcard cert for {{*.example.com}}
> and a cluster consists of {{nf1.example.com}}, {{nf2.example.com}}, and
> {{nf3.example.com}} . We cannot transfer a FlowFile between nodes for load
> balancing because of the following authorization error:
> {noformat}
> 2018-10-25 19:05:13,520 WARN [Load Balance Server Thread-2]
> o.a.n.c.q.c.s.ClusterLoadBalanceAuthorizer Authorization failed for Client
> ID's [*.example.com] to Load Balance data because none of the ID's are known
> Cluster Node Identifiers
> 2018-10-25 19:05:13,521 ERROR [Load Balance Server Thread-2]
> o.a.n.c.q.c.s.ConnectionLoadBalanceServer Failed to communicate with Peer
> /xxx.xxx.xxx.xxx:xxxxx
> org.apache.nifi.controller.queue.clustered.server.NotAuthorizedException:
> Client ID's [*.example.com] are not authorized to Load Balance data
> at
> org.apache.nifi.controller.queue.clustered.server.ClusterLoadBalanceAuthorizer.authorize(ClusterLoadBalanceAuthorizer.java:65)
> at
> org.apache.nifi.controller.queue.clustered.server.StandardLoadBalanceProtocol.receiveFlowFiles(StandardLoadBalanceProtocol.java:142)
> at
> org.apache.nifi.controller.queue.clustered.server.ConnectionLoadBalanceServer$CommunicateAction.run(ConnectionLoadBalanceServer.java:176)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This problem occurs because in {{authorize}} method in
> {{ClusterLoadBalanceAuthorizer}} class, authorization is tried by just
> matching strings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
