[
https://issues.apache.org/jira/browse/IGNITE-29256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29256:
--------------------------------------
Description:
IGNITE-29209 lets a factory replace its cached SSL context. Outgoing
communication already obtains that context for each connection. Discovery,
incoming communication, the client connector and binary REST retain the startup
context, so replacing the factory cache does not change the keys or trust used
by their new connections.
Make these transports use the replacement. The administrator command follows in
IGNITE-29210; this ticket verifies reload through the factory API.
h3. What to change
# For {{AbstractSslContextFactory}}, obtain its current context for every new
connection. Cover both directions of discovery and communication, plus the
client connector and binary REST.
# Keep established connections open. During loading and after a failed reload,
new connections must still use the previous context. Preserve server mode,
client authentication, handshake timeouts, protocols, cipher suites and startup
validation.
# Use one discovery socket path for all factory types. Other factory types keep
their startup context for discovery and incoming connections; outgoing
communication keeps calling their factory for each connection.
# If context lookup or TLS setup fails on an accepted discovery socket, close
that socket and keep accepting connections. In NIO, a context lookup failure
must close only the affected session and leave the worker running.
h3. Custom factories and compatibility
Document that Ignite calls {{AbstractSslContextFactory.create()}} for every new
connection, including on NIO threads. Custom discovery contexts must support
engine creation for startup checks, TLS wrapping of an accepted socket and
server mode. Settings supplied only by a custom server socket factory no longer
affect discovery connections.
Keep {{TcpDiscoverySpi.sslSockFactory}} and {{sslSrvSockFactory}} as deprecated
protected fields so subclasses can still reference them. They retain their
startup values. Reload does not update them, and assigning them no longer
changes connections. State both limits in their Javadoc.
h3. Done when
* A test reloads a running node's factory, then confirms replacement keys and
trust on every TCP transport, including both directions of discovery and
communication.
* Established connections stay usable. New connections use the old material
during loading and after a failed load.
* A shared factory and an ordinary factory work through the same discovery
path. After an injected lookup or socket-setup failure, discovery accepts the
next connection; an NIO lookup failure leaves the worker usable.
Depends on IGNITE-29209. The command, scheduling and HTTP REST are separate
tickets.
[Implementation plan in PR #13795|https://github.com/apache/ignite/pull/13795]
was:
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]
> 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
>
> IGNITE-29209 lets a factory replace its cached SSL context. Outgoing
> communication already obtains that context for each connection. Discovery,
> incoming communication, the client connector and binary REST retain the
> startup context, so replacing the factory cache does not change the keys or
> trust used by their new connections.
> Make these transports use the replacement. The administrator command follows
> in IGNITE-29210; this ticket verifies reload through the factory API.
> h3. What to change
> # For {{AbstractSslContextFactory}}, obtain its current context for every new
> connection. Cover both directions of discovery and communication, plus the
> client connector and binary REST.
> # Keep established connections open. During loading and after a failed
> reload, new connections must still use the previous context. Preserve server
> mode, client authentication, handshake timeouts, protocols, cipher suites and
> startup validation.
> # Use one discovery socket path for all factory types. Other factory types
> keep their startup context for discovery and incoming connections; outgoing
> communication keeps calling their factory for each connection.
> # If context lookup or TLS setup fails on an accepted discovery socket, close
> that socket and keep accepting connections. In NIO, a context lookup failure
> must close only the affected session and leave the worker running.
> h3. Custom factories and compatibility
> Document that Ignite calls {{AbstractSslContextFactory.create()}} for every
> new connection, including on NIO threads. Custom discovery contexts must
> support engine creation for startup checks, TLS wrapping of an accepted
> socket and server mode. Settings supplied only by a custom server socket
> factory no longer affect discovery connections.
> Keep {{TcpDiscoverySpi.sslSockFactory}} and {{sslSrvSockFactory}} as
> deprecated protected fields so subclasses can still reference them. They
> retain their startup values. Reload does not update them, and assigning them
> no longer changes connections. State both limits in their Javadoc.
> h3. Done when
> * A test reloads a running node's factory, then confirms replacement keys and
> trust on every TCP transport, including both directions of discovery and
> communication.
> * Established connections stay usable. New connections use the old material
> during loading and after a failed load.
> * A shared factory and an ordinary factory work through the same discovery
> path. After an injected lookup or socket-setup failure, discovery accepts the
> next connection; an NIO lookup failure leaves the worker usable.
> Depends on IGNITE-29209. The command, scheduling and HTTP REST are separate
> tickets.
> [Implementation plan in PR #13795|https://github.com/apache/ignite/pull/13795]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
