Thanks a lot. It was a clean cherry-pick indeed and the fix works on my 1.20 cluster.
On Fri, Nov 28, 2025 at 6:40 PM Gabor Somogyi <[email protected]> wrote: > > No need to create/reopen, I'm going to punt that in as soon as azure passed > > G > > > On Fri, Nov 28, 2025 at 4:47 PM Gyula Komlossi <[email protected]> wrote: >> >> Thanks Gabor, I created a PR for it: >> https://github.com/apache/flink/pull/27284 >> If I understand correctly, there is no need for a new ticket or >> reopening the old one for this. >> >> On Thu, Nov 27, 2025 at 6:33 PM Gabor Somogyi <[email protected]> >> wrote: >> > >> > 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 >> >> > >>> > > > > > > > > > > > >> >> > >>> > > > > > > > > > > >> >> > >>> > > > > > > > > > >> >> > >>> > > > > > > > > >> >> > >>> > > > > > > > >> >> > >>> > > > > > > >> >> > >>> > > > > > >> >> > >>> > > > > >> >> > >>> > > > >> >> > >>> > > >> >> > >>> >
