[
https://issues.apache.org/jira/browse/IGNITE-29256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29256:
--------------------------------------
Description:
Make new TCP connections use the current SSL context after a factory reload.
Outgoing communication already picks up the replacement. Discovery, incoming
communication, the client connector and binary REST still use the context from
startup.
h3. What to deliver
# For {{AbstractSslContextFactory}}, use its current context on every new
connection. Cover discovery and communication in both directions, plus the
client connector and binary REST.
# Other factory types keep their startup context for discovery and incoming
connections. Outgoing communication still calls the factory for each connection.
# Keep established connections open. New connections use the previous context
while loading and after a failed reload. Preserve server mode, client
authentication, handshake timeouts, protocols, cipher suites and startup checks.
# If TLS setup fails on one accepted discovery socket, keep the listener
available for the next connection.
h3. Compatibility
Ignite calls {{create()}} on an {{AbstractSslContextFactory}} for each new
connection, including on NIO threads. Discovery uses the same socket setup for
every factory type. A custom context must create a TLS engine for startup
validation. It must also layer TLS over an accepted socket and let Ignite set
server mode. Discovery stops applying settings that only a custom server socket
factory supplied.
Keep the protected {{TcpDiscoverySpi.sslSockFactory}} and {{sslSrvSockFactory}}
fields and mark them {{@Deprecated}}. Subclasses can still reference the
startup values. Reload leaves the fields as they are, and assigning either
field no longer affects discovery. Explain both limits in their Javadoc.
h3. Acceptance
* Call {{init()}} from a test on a running node. Verify key and trust rotation
on all four transports, including both directions of discovery and
communication.
* Check that an established connection stays usable. Check that new connections
still use the old material during loading and after a failed load.
* Test a shared factory and an ordinary factory joining through the same
discovery path.
* After a context lookup or socket setup failure, verify that discovery accepts
another connection. Verify that a failed context lookup closes only the
affected NIO session.
Depends on IGNITE-29209. IGNITE-29210 adds the command. Scheduling and HTTP
REST are separate.
[Implementation plan in PR #13795|https://github.com/apache/ignite/pull/13795]
was:
On a running node, outgoing communication connections already pick up the
context after {{init()}}. Discovery, incoming communication, the client
connector and binary REST keep the context they obtained at startup. Make new
connections on all four transports use the current context.
h3. What to deliver
# Use the current context of an {{AbstractSslContextFactory}} for each new
discovery and communication connection in both directions, and for new client
connector and binary REST connections. Other factory types keep their startup
context in discovery and incoming transports; outgoing communication keeps its
existing factory calls.
# Keep established connections open. During a reload and after a failed reload,
new connections use the previous context. Keep server mode, client
authentication, handshake timeouts, protocols, cipher suites and existing
startup checks. A failure setting up TLS on one accepted discovery socket
leaves the listener available.
h3. Compatibility
For an {{AbstractSslContextFactory}}, Ignite calls {{create()}} for each new
connection, including on NIO threads. Discovery uses the same socket setup path
for all factory types. A custom context must support engine creation for
startup validation, layering TLS over an accepted socket and setting server
mode. Settings applied only by a custom server socket factory no longer affect
discovery connections.
Keep the protected {{TcpDiscoverySpi.sslSockFactory}} and {{sslSrvSockFactory}}
fields and mark them {{@Deprecated}}. Existing subclasses can still reference
them. Discovery no longer reads them, reload leaves their startup values in
place, and assigning either field in a subclass no longer affects connections.
State these limits in the fields' Javadoc.
h3. Acceptance
Call {{init()}} on a running node from a test and verify key and trust rotation
on new connections across the four transports, including both directions of
discovery and communication. Check that an established connection stays usable
and a new connection still uses the old material during loading and after
failure. Cover a factory shared by multiple transports and confirm that the
discovery listener accepts another connection after a context lookup or socket
setup failure. Verify that an ordinary factory can join through the same
discovery path and that a failed context lookup closes only the affected NIO
session.
Depends on IGNITE-29209. The management command belongs to IGNITE-29210.
Scheduling and HTTP REST are separate.
[Implementation plan: PR #13795|https://github.com/apache/ignite/pull/13795]
> Use the factory's current SSL context for new TCP connections
> -------------------------------------------------------------
>
> Key: IGNITE-29256
> URL: https://issues.apache.org/jira/browse/IGNITE-29256
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Make new TCP connections use the current SSL context after a factory reload.
> Outgoing communication already picks up the replacement. Discovery, incoming
> communication, the client connector and binary REST still use the context
> from startup.
> h3. What to deliver
> # For {{AbstractSslContextFactory}}, use its current context on every new
> connection. Cover discovery and communication in both directions, plus the
> client connector and binary REST.
> # Other factory types keep their startup context for discovery and incoming
> connections. Outgoing communication still calls the factory for each
> connection.
> # Keep established connections open. New connections use the previous context
> while loading and after a failed reload. Preserve server mode, client
> authentication, handshake timeouts, protocols, cipher suites and startup
> checks.
> # If TLS setup fails on one accepted discovery socket, keep the listener
> available for the next connection.
> h3. Compatibility
> Ignite calls {{create()}} on an {{AbstractSslContextFactory}} for each new
> connection, including on NIO threads. Discovery uses the same socket setup
> for every factory type. A custom context must create a TLS engine for startup
> validation. It must also layer TLS over an accepted socket and let Ignite set
> server mode. Discovery stops applying settings that only a custom server
> socket factory supplied.
> Keep the protected {{TcpDiscoverySpi.sslSockFactory}} and
> {{sslSrvSockFactory}} fields and mark them {{@Deprecated}}. Subclasses can
> still reference the startup values. Reload leaves the fields as they are, and
> assigning either field no longer affects discovery. Explain both limits in
> their Javadoc.
> h3. Acceptance
> * Call {{init()}} from a test on a running node. Verify key and trust
> rotation on all four transports, including both directions of discovery and
> communication.
> * Check that an established connection stays usable. Check that new
> connections still use the old material during loading and after a failed load.
> * Test a shared factory and an ordinary factory joining through the same
> discovery path.
> * After a context lookup or socket setup failure, verify that discovery
> accepts another connection. Verify that a failed context lookup closes only
> the affected NIO session.
> Depends on IGNITE-29209. IGNITE-29210 adds the command. Scheduling and HTTP
> REST are separate.
> [Implementation plan in PR #13795|https://github.com/apache/ignite/pull/13795]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
