[
https://issues.apache.org/jira/browse/IGNITE-16627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701724#comment-17701724
]
Semyon Danilov commented on IGNITE-16627:
-----------------------------------------
The problem:
There is a SSL gateway proxy in k8s cluster. In order to connect to a node of
the cluster, SNI extension must be provided. Otherwise SSL gateway doesn’t know
where to route incoming traffic.
A thin client is located outside of the k8s cluster. It is aware of some
address (probably the address of the gateway). As a WA a custom SSLFactory
might be implemented, which provides SNI extension. However, this way thin
client can only connect to one node (the one whose Server Name is provided). So
when a client learns (through affinity awareness) of other nodes, it won’t be
able to connect to them, outgoing traffic will always be routed to the first
node with provided Server Name. This means that there’s a single point of
denial and that load will be unbalanced.
Implementation problem(s):
According to the TLS protocol, we can only set one Server Name per connection.
ATM we have one SSLContext per all connections. Looks like we need to have a
context per connection. By default, we should set each address (if it is a
hostname) from ClientConfiguration as a Server Name for a connection to that
address. In case we are learning about a node “in runtime” – we should cycle
through it’s addresses and use hostname as Server Name for connections. There
can be a problem if we get an IP of a node (that will probably be the internal
k8s cluster IP) – we most likely won’t be able to connect to it. However we
should be able to connect by hostname
> SNI extension is missing when Java thin client is connecting to Ignite
> cluster with SSL enabled
> -----------------------------------------------------------------------------------------------
>
> Key: IGNITE-16627
> URL: https://issues.apache.org/jira/browse/IGNITE-16627
> Project: Ignite
> Issue Type: Bug
> Components: thin client
> Affects Versions: 2.11
> Reporter: Maria Makedonskaya
> Priority: Major
>
> Motivation: There are cases then ignite clients are connecting to a cluster
> which is located inside Kubernetes(k8s) and k8s cluster has an ingress
> gateway that routes TLS traffic using SNI extension.
> Need to provide hostnames from
> org.apache.ignite.configuration.ClientConfiguration#setAddresses to SNI
> extention.
> SSLContext for java thin client is creating in
> org.apache.ignite.internal.client.thin.ClientSslUtils#getSslContext. Possibly
> we can use org.apache.ignite.ssl.SSLContextWrapper there to provide
> additional SSLParameters(like it's done in
> org.apache.ignite.ssl.SslContextFactory#createSslContext). For adding SNI
> extension need to add hostnames via
> javax.net.ssl.SSLParameters#setServerNames.
> Also need to check that other thin clients and thick clients add SNI to
> handshake.
> Possibly in
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter#onSessionOpened we
> need additionally to replace
> from:
> {code:java}
> engine = this.sslCtx.createSSLEngine();{code}
> to:
> {code:java}
> engine = this.sslCtx.createSSLEngine(ses.remoteAddress().getHostName(),
> ses.remoteAddress().getPort()){code}
> In this case, if an IP address is set to ClientConfiguration#setAddresses
> then SNI extension will be added with reverse lookup hostname. If hostname
> with a port is set to ClientConfiguration#setAddresses no SNI extension will
> be added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
