Hi Yaroslav, Gabor, I just ran into this issue, when tried to configure SSL for the REST endpoint. I'm wondering what the preferred approach is with HTTPS on this REST endpoint or if there is any code change in progress. Have you been able to solve this one way or another, or started preparing a code change for it?
I was able to make this work with a small code change in the RestServerEndpoint class to use the rest.address as the advertisedAddress with HTTPS, but I’m looking forward to the official improvement. Thank you both for taking care of this! Best, Gyula On 2025/08/19 20:34:06 Yaroslav Chernysh wrote: > https://issues.apache.org/jira/browse/FLINK-38269 > > On 2025/08/19 18:58:59 Gabor Somogyi wrote: > > You can file a jira and open a PR too so feel free. > > > > G > > > > On Tue, Aug 19, 2025, 19:51 Yaroslav Chernysh <[email protected]> wrote: > > > > > Hi Gabor, > > > > > > > > > Just to avoid any misunderstanding, I've been waiting for the ticket > > > from you. I assumed that you were going to do it. Please let me know if > > > I got you wrong and I should create it myself. > > > > > > > > > Best regards, > > > > > > Yaroslav > > > > > > > > > On 2025/08/18 14:07:51 Gabor Somogyi wrote: > > > > Yeah, please read the how to contribute guide if you haven't done > > > already. > > > > > > > > G > > > > > > > > On Mon, Aug 18, 2025 at 4:00 PM Yaroslav Chernysh <[email protected]> > > > > wrote: > > > > > > > > > Hi Gabor, > > > > > > > > > > > > > > > Thanks, let's add a new option then to make advertised address > > > > > configurable and document the default behavior. Would you mind > filing > > > a > > > > > ticket for that? > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Yaroslav > > > > > > > > > > > > > > > On 2025/08/18 13:41:54 Gabor Somogyi wrote: > > > > > > Hi Yaroslav, > > > > > > > > > > > > Having a config option to advertise something else is what I can > > > > > support. > > > > > > Needless to say the actual behavior would remain as default. > > > > > > > > > > > > G > > > > > > > > > > > > > > > > > > On Mon, Aug 18, 2025 at 3:28 PM Yaroslav Chernysh > <[email protected]> > > > > > > wrote: > > > > > > > > > > > > > Hi Gabor, > > > > > > > > > > > > > > I got your point on using `getHostName()`. Thank you for such a > > > > > detailed > > > > > > > explanation. > > > > > > > > > > > > > > What do you think about advertising rest.address instead? In > > > case of > > > > > > > YARN (at least on my environment), this is already set by YARN > > > to a NM > > > > > > > hostname, so rDNS would be avoided. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Yaroslav > > > > > > > > > > > > > > > > > > > > > On 2025/08/15 21:12:58 Gabor Somogyi wrote: > > > > > > > > Hi Yaroslav, > > > > > > > > > > > > > > > > Thanks for your efforts in finding out all the details. > > > > > > > > > > > > > > > > I think making `getHostName` possible with a config + some > > > > > additional > > > > > > > > warnings in the documentation can be considered. > > > > > > > > You need to evaluate your security standards but you win > > > something > > > > > on > > > > > > > one > > > > > > > > side and introduce new attack vector on the other side. > > > > > > > > > > > > > > > > I would write something similar in the documentation, and > I also > > > > > suggest > > > > > > > > you consider these for your own situation as well: > > > > > > > > - rDNS is not trustworthy for security decisions. > Attackers with > > > > > control > > > > > > > > over PTR (or via poisoning/misconfig) can return arbitrary > > > names. > > > > > > > > MITRE tracks this as CWE-350 [1] (Reliance on Reverse DNS for > > > > > > > Security). If > > > > > > > > you base TLS host checks on rDNS, it’s bypassable. > > > > > > > > - Slow or failing DNS causes blocking delays (seconds) in JVM > > > > > lookups. > > > > > > > > OpenJDK issues document repeated timeouts and lack of > > > > > > > > effective caching paths for some rDNS calls. Putting rDNS in > > > > > critical > > > > > > > paths > > > > > > > > (TLS, handshake, request handling) can amplify random > outages. > > > > > > > > > > > > > > > > All in all I'm not yet convinced that this issue appears in > > > other > > > > > > > trending > > > > > > > > environments like k8s. > > > > > > > > Adding this together with the mentioned risks I personally > > > wouldn't > > > > > > > merge > > > > > > > > it to the main repo. > > > > > > > > > > > > > > > > BR, > > > > > > > > G > > > > > > > > > > > > > > > > [1] https://cwe.mitre.org/data/definitions/350.html > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Aug 15, 2025 at 7:44 PM Yaroslav Chernysh > > > <[email protected]> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hi Gobor, > > > > > > > > > > > > > > > > > > Thank you for such a quick response, I appreciate it. > > > > > > > > > > > > > > > > > > Actually, I'm not very good at all this security and > > > networking > > > > > > > stuff, so > > > > > > > > > I apologize in advance if I'm wrong in some statement. > > > > > > > > > > > > > > > > > > > Does YARN containers share the host’s network in your > case? > > > > > > > > > > > > > > > > > > Yes, it does. And as far as I have researched, it > always does, > > > > > > > possibly > > > > > > > > > only unless you have configured YARN to use Docker > containers > > > > > > > > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > > > > https://hadoop.apache.org/docs/r3.4.1/hadoop-yarn/hadoop-yarn-site/DockerContainers.html > > > > > > > >, > > > > > > > > > which is definitely not my case. I have also done some > > > testing on > > > > > > > my node, > > > > > > > > > which has 2 IP addresses: > > > > > > > > > > > > > > > > > > - With default rest.bind-address (set by YARN to Node > > > Manager's > > > > > > > hostname), > > > > > > > > > the only IP address that opens a port is the one that NM > > > > > hostname is > > > > > > > > > resolved to. The other one (not sure where it comes from, > > > this is > > > > > a > > > > > > > VM) > > > > > > > > > remains closed > > > > > > > > > > > > > > > > > > - With rest.bind-address set to 0.0.0.0, the port is > open and > > > > > > > accessible > > > > > > > > > via both IP addresses > > > > > > > > > > > > > > > > > > > However if you have a single IP then using 0.0.0.0 and > > > > > binding it to > > > > > > > > > lo + eth0 is something what I wouldn't worry about. > > > > > > > > > > > > > > > > > > I got the point and basically I agree here, but I'm not > > > sure how > > > > > > > > > future-proof this approach is. How probable is a > scenario in > > > > > which the > > > > > > > > > environment (single IP node) is changed (to a multi-homed > > > > > node), but > > > > > > > > > unchanged configuration (still listening on 0.0.0.0) > now leads > > > > > to an > > > > > > > > > excessive network exposure? Either way, that's not my case. > > > And I > > > > > > > think > > > > > > > > > this is not restricted to YARN too: binding to all > > > interfaces in > > > > > > > Standalone > > > > > > > > > deployment might be too excessive as well. > > > > > > > > > > > > > > > > > > > but you still have control on firewall, right? > > > > > > > > > > > > > > > > > > Probably yes (saying for an average user). This would > probably > > > > > > > cover the > > > > > > > > > excessive binding leak, however only at the firewall level > > > and not > > > > > > > at the > > > > > > > > > "core". This adds a dependency on firewall. I'm not saying > > > it's > > > > > > > bad, but > > > > > > > > > rather that using the defense-in-depth approach and > doing both > > > > > limited > > > > > > > > > binding and adding firewall would be even better than > > > relying on > > > > > > > firewall > > > > > > > > > only. > > > > > > > > > > > > > > > > > > I hope all the above proves the point that even with good > > > enough > > > > > > > > > environment (number of IP address + firewall) it still does > > > make > > > > > > > sense to > > > > > > > > > restrict the binding. At least that's how I see this, > please > > > > > > > correct me if > > > > > > > > > I'm wrong. > > > > > > > > > > > > > > > > > > > introduce reverse DNS lookup as a must have feature > > > > > > > > > > > > > > > > > > Could we make it optional and disabled by default? > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > Yaroslav > > > > > > > > > > > > > > > > > > On 2025/08/14 21:32:40 Gabor Somogyi wrote: > > > > > > > > > > Hi Yaroslav, > > > > > > > > > > > > > > > > > > > > First of all I would like to understand why you think > > > binding to > > > > > > > 0.0.0.0 > > > > > > > > > is > > > > > > > > > > less secure in your case. Correct me if I'm wrong: > > > > > > > > > > Does YARN containers share the host’s network in your > > > case? On a > > > > > > > > > > multi-homed node, 0.0.0.0 exposes on every host > interface, > > > > > > > > > > which can be less secure than binding to a specific host > > > IP. So > > > > > > > this case > > > > > > > > > > pinning can matter. > > > > > > > > > > > > > > > > > > > > However if you have a single IP then using 0.0.0.0 and > > > binding > > > > > it > > > > > > > to lo + > > > > > > > > > > eth0 is something what I wouldn't worry about. > > > > > > > > > > Like a "normal" kubernetes pod (default networking, > single > > > > > > > interface, no > > > > > > > > > > hostNetwork) has no such issue. > > > > > > > > > > > > > > > > > > > > As a general remark. Let's say you expose the REST > endpoint > > > > > on 2 IP > > > > > > > > > > addresses but you still have control on firewall, right? > > > > > > > > > > > > > > > > > > > > The main reason why I'm asking these questions is because > > > using > > > > > > > > > > `getHostName` would introduce reverse DNS lookup as a > > > must have > > > > > > > feature. > > > > > > > > > > That could cause quite some turbulences at heavy users by > > > > > additional > > > > > > > > > > traffic, PTR records can be wrong or spoofed, etc... > > > > > > > > > > > > > > > > > > > > BR, > > > > > > > > > > G > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Aug 14, 2025 at 8:13 PM Yaroslav Chernysh > > > > > <[email protected]> > > > > > > > > > <[email protected]> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi Flink community, > > > > > > > > > > > > > > > > > > > > > > Is there a particular reason to advertise Job Manager's > > > REST > > > > > > > endpoint > > > > > > > > > > > address in a form of IP address instead of > hostname? More > > > > > > > precisely, > > > > > > > > > I'm > > > > > > > > > > > talking about this code block > > > > > > > > > > > > > > > > > > > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/flink/blob/release-2.0.0/flink-runtime/src/main/java/org/apache/flink/runtime/rest/RestServerEndpoint.java#L298-L304 > > > > > > > > > > > > > > > > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/flink/blob/release-2.0.0/flink-runtime/src/main/java/org/apache/flink/runtime/rest/RestServerEndpoint.java#L298-L304 > > > > > > > > > > > > > > > > > in > > > > > > > > > > > RestServerEndpoint.java: > > > > > > > > > > > > > > > > > > > > > > final InetSocketAddress bindAddress = > (InetSocketAddress) > > > > > > > > > > > serverChannel.localAddress(); > > > > > > > > > > > final String advertisedAddress; > > > > > > > > > > > if (bindAddress.getAddress().isAnyLocalAddress()) { > > > > > > > > > > > advertisedAddress = this.restAddress; > > > > > > > > > > > } else { > > > > > > > > > > > advertisedAddress = > > > > > > > > > > > bindAddress.getAddress().getHostAddress(); > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > That is (as far as I understood), if rest.bind-address > > > is set > > > > > > > to the > > > > > > > > > > > 0.0.0.0 wildcard (which means binding to all available > > > > > > > interfaces), > > > > > > > > > then > > > > > > > > > > > the advertised address will be the value of > rest.address. > > > > > > > Otherwise, an > > > > > > > > > > > address in a form of IP address of the specified > > > > > rest.bind-address > > > > > > > > > will be > > > > > > > > > > > used. > > > > > > > > > > > What if I want to bind the REST endpoint to some > specific > > > > > > > address (for > > > > > > > > > > > security reasons), but at the same time advertise it in > > > the > > > > > form > > > > > > > of > > > > > > > > > > > hostname? Assuming that all the name resolution things > > > work > > > > > > > correctly. > > > > > > > > > > > > > > > > > > > > > > For me particularly, the problem this creates is with > > > SSL. The > > > > > > > > > certificate > > > > > > > > > > > I have for the Job Manager (REST connectivity) is > created > > > > > with a > > > > > > > > > hostname > > > > > > > > > > > and not an IP address. I run Flink on YARN and this way > > > the > > > > > > > default > > > > > > > > > value > > > > > > > > > > > for rest.bind-address is Node Manager's hostname (thus, > > > not > > > > > the > > > > > > > 0.0.0.0 > > > > > > > > > > > wildcard), and the same goes for rest.address. This > > > way, the > > > > > > > advertised > > > > > > > > > > > address is in the form of an IP address. I'd like to > > > access > > > > > > > Flink's UI > > > > > > > > > via > > > > > > > > > > > the YARN Resource Manager proxy ("Tracking URL" in the > > > > > application > > > > > > > > > page) > > > > > > > > > > > that has the Job Manager's certificate in its > truststore. > > > > > > > However, due > > > > > > > > > to > > > > > > > > > > > the Flink being advertised to Resource Manager with > the IP > > > > > > > address and > > > > > > > > > the > > > > > > > > > > > certificate holds the hostname, the connection from > > > Resource > > > > > > > Manager > > > > > > > > > to Job > > > > > > > > > > > Manager fails with: > > > > > > > > > > > > > > > > > > > > > > javax.net.ssl.SSLPeerUnverifiedException: > Certificate for > > > > > > > > > <192.168.33.11> > > > > > > > > > > > doesn't match any of the subject alternative names: [] > > > > > > > > > > > > > > > > > > > > > > The only way I can fix this (without code changes) > is by > > > > > > > explicitly > > > > > > > > > > > setting rest.bind-address to 0.0.0.0, which is not > > > secure, as > > > > > > > far as I > > > > > > > > > > > understand (less secure than binding to a specific > > > address). > > > > > > > > > > > However, if I substitute the getHostAddress() call in > > > the code > > > > > > > block > > > > > > > > > above > > > > > > > > > > > with the getHostName(), the issue is gone. > > > > > > > > > > > > > > > > > > > > > > So, my question is: is there any particular reason > not to > > > > > > > > > > > use getHostName() here (assuming hostname is > available)? > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Yaroslav > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
