[supplement to my last email]
Also, how about advertising to rest.address instead of IP address form
of rest.bind-address? At least for YARN case, where rest.address is
forcefully overwritten to Node Manager's hostname, this should solve the
problem. Not sure about other runtime environments.
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 <ya...@gmail.com>
> 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>
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
> >
>
