1.20 is an LTS version so go on. G
On Thu, Nov 27, 2025, 18:00 Gyula Komlossi <[email protected]> wrote: > While trying to make the REST endpoints on my 1.20 Flink environment > work with SSL, I discovered that the 0.0.0.0 bind-address solution > won't work in this release. > > It is because in YarnEntrypointUtils, the bind address is overwritten > with the hostname, before it was used for creating the endpoint :) > > https://github.com/apache/flink/blob/release-1.20/flink-yarn/src/main/java/org/apache/flink/yarn/entrypoint/YarnEntrypointUtils.java#L68 > > This commit should be cherry-picked to release-1.20. if we want to make it > work: > > https://github.com/apache/flink/commit/b138d47adbed9fc1e5a73cebf649530bc5b89e6e > > Do you think it's worth a Jira and the effort? Will there be more 1.20 > bugfix releases in the future? > > Thanks, > Gyula > > On Thu, Nov 27, 2025 at 9:51 AM Gyula Komlossi <[email protected]> > wrote: > > > > Hi Gabor, > > > > Thanks for the quick response. I was wondering how a third config > > parameter cloud be avoided. There are two already (rest.address and > > rest.bind-address) and a third one would make confusion, but I > > understand, the existing behavior shouldn't be changed. > > Also the rest.address is supposed to be "The address that should be > > used by clients to connect to the server". Just like with the Kafka > > advertised listeners. > > > > For my testing I just added an extra condition to this: > > if (bindAddress.getAddress().isAnyLocalAddress() || isHttpsEnabled()) { > > advertisedAddress = this.restAddress; > > } else { > > advertisedAddress = bindAddress.getAddress().getHostAddress(); > > } > > but it's far from ideal, it's just a workaround for now :) > > > > So I don't have a real alternative for this.. > > > > Best, > > Gyula > > > > On Thu, Nov 27, 2025 at 9:04 AM Gabor Somogyi <[email protected]> > wrote: > > > > > > BTW if you have any alternative way just share it either in the jira > or in PR 🙂 > > > > > > On Thu, Nov 27, 2025 at 9:02 AM Gabor Somogyi < > [email protected]> wrote: > > >> > > >> Hi Gyula, > > >> > > >> We've discussed the issue but no PR available yet. > > >> Feel free and cc me if you have time... > > >> > > >> BR, > > >> G > > >> > > >> > > >> On Thu, Nov 27, 2025 at 8:52 AM Gyula Komlossi <[email protected]> > wrote: > > >>> > > >>> 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 > > >>> > > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > >
