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
>>> > > > > > > > > > > >
>>> > > > > > > > > > >
>>> > > > > > > > > >
>>> > > > > > > > >
>>> > > > > > > >
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
