[
https://issues.apache.org/jira/browse/IGNITE-29210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29210:
--------------------------------------
Description:
Factories can reload key and trust stores, and new TCP connections can use the
updated context. Administrators still have no command to trigger that reload
across running nodes. Add {{control.sh --ssl reload}} to load updated key and
trust stores and show which nodes succeeded.
h3. What the command must do
# Target all server and thick-client nodes in the current topology. Reload
factories used by TCP discovery, communication, the client connector and binary
REST that actually started with TLS. Configuration alone is not enough: a
binary REST listener may fail to bind a port. Reload a shared factory once per
node and report all transports using it.
# Require {{ADMIN_OPS}} and confirmation, with {{--yes}} to skip the prompt.
Each node logs the outcome and, when security is enabled, the initiator.
# Before reloading, each node checks that all its factories support reload. If
any factory is unsupported, reload nothing on that node. Otherwise, stop at the
first reload failure. Keep successful replacements and their log records; other
nodes continue independently.
# Report every target, including nodes with no TCP transports using TLS. Return
an error if any target fails, uses an unsupported factory or leaves before
responding. A result received from a node stays in the report even if the node
leaves later.
The command does not reload TLS for the HTTP REST endpoint (Jetty).
h3. Which factories can reload
Use {{AbstractSslContextFactory.init()}} and make it public. Run reloads of the
same factory one at a time; cached {{create()}} calls can keep returning the
working context during loading. Report factory types that do not extend
{{AbstractSslContextFactory}} as unsupported.
Document the contract for custom factories: an overridden {{create()}} must
obtain the context from {{super.create()}} on every call. The key and trust
loading hooks must read fresh material for their changes to take effect. Trust
managers supplied through {{setTrustManagers()}} are reused.
h3. Operator instructions
Update “Upgrading Certificates” in the SSL/TLS guide: prepare peer trust across
the cluster, replace stores at the configured paths with the same passwords,
run reload and verify a new connection. To recover from a bad replacement,
restore the previous files and reload again. Changing node configuration
requires a restart.
h3. Done when
The control utility applies a replacement on servers and thick clients, and a
new connection confirms it. Tests cover shared and custom factories, concurrent
reloads of the same factory, confirmation, permissions and logs. Tests verify
that an unsupported factory prevents all reloads on its node, and that a failed
reload prevents later reloads there. The report retains results from other
nodes. A listener that did not start must not appear as reloaded; a node with
no TCP transports using TLS must still appear.
Depends on IGNITE-29256. This ticket adds the command and its documentation,
not a separate status command, new certificate-date checks or background
monitoring.
[Implementation plan in PR #13785|https://github.com/apache/ignite/pull/13785]
was:
Factories can reload key and trust stores, and new TCP connections can use the
updated context. Administrators still have no command to trigger that reload
across running nodes. Add {{control.sh --ssl reload}} to load updated key and
trust stores and show which nodes succeeded.
h3. What the command must do
# Target all server and thick-client nodes in the current topology. Reload
factories used by TCP discovery, communication, the client connector and binary
REST that actually started with TLS. Configuration alone is not enough: a
binary REST listener may fail to bind a port. Reload a shared factory once per
node and report all transports using it.
# Require {{ADMIN_OPS}} and confirmation, with {{--yes}} to skip the prompt.
Each node logs the outcome and, when security is enabled, the initiator.
# Report every target, including nodes with no TCP transports using TLS.
Continue after individual failures and retain successful replacements. Return
an error if any target fails, uses an unsupported factory or leaves before
responding. Keep the full report. A result received from a node stays in the
report even if the node leaves later.
The command does not reload TLS for the HTTP REST endpoint (Jetty).
h3. Which factories can reload
Use {{AbstractSslContextFactory.init()}} and make it public. Run reloads of the
same factory one at a time; cached {{create()}} calls can keep returning the
working context during loading. Report factory types that do not extend
{{AbstractSslContextFactory}} as unsupported.
Document the contract for custom factories: an overridden {{create()}} must
obtain the context from {{super.create()}} on every call. The key and trust
loading hooks must read fresh material for their changes to take effect. Trust
managers supplied through {{setTrustManagers()}} are reused.
h3. Operator instructions
Update “Upgrading Certificates” in the SSL/TLS guide: prepare peer trust across
the cluster, replace stores at the configured paths with the same passwords,
run reload and verify a new connection. To recover from a bad replacement,
restore the previous files and reload again. Changing node configuration
requires a restart.
h3. Done when
The control utility applies a replacement on servers and thick clients, and a
new connection confirms it. Tests cover shared and custom factories, concurrent
reloads of the same factory, confirmation, permissions and logs. The report
must retain successes alongside failures, unsupported factories and departed
nodes. A listener that did not start must not appear as reloaded; a node with
no TCP transports using TLS must still appear.
Depends on IGNITE-29256. This ticket adds the command and its documentation,
not a separate status command, new certificate-date checks or background
monitoring.
[Implementation plan in PR #13785|https://github.com/apache/ignite/pull/13785]
> Reload TLS certificates on running nodes
> ----------------------------------------
>
> Key: IGNITE-29210
> URL: https://issues.apache.org/jira/browse/IGNITE-29210
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Labels: ise
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Factories can reload key and trust stores, and new TCP connections can use
> the updated context. Administrators still have no command to trigger that
> reload across running nodes. Add {{control.sh --ssl reload}} to load updated
> key and trust stores and show which nodes succeeded.
> h3. What the command must do
> # Target all server and thick-client nodes in the current topology. Reload
> factories used by TCP discovery, communication, the client connector and
> binary REST that actually started with TLS. Configuration alone is not
> enough: a binary REST listener may fail to bind a port. Reload a shared
> factory once per node and report all transports using it.
> # Require {{ADMIN_OPS}} and confirmation, with {{--yes}} to skip the prompt.
> Each node logs the outcome and, when security is enabled, the initiator.
> # Before reloading, each node checks that all its factories support reload.
> If any factory is unsupported, reload nothing on that node. Otherwise, stop
> at the first reload failure. Keep successful replacements and their log
> records; other nodes continue independently.
> # Report every target, including nodes with no TCP transports using TLS.
> Return an error if any target fails, uses an unsupported factory or leaves
> before responding. A result received from a node stays in the report even if
> the node leaves later.
> The command does not reload TLS for the HTTP REST endpoint (Jetty).
> h3. Which factories can reload
> Use {{AbstractSslContextFactory.init()}} and make it public. Run reloads of
> the same factory one at a time; cached {{create()}} calls can keep returning
> the working context during loading. Report factory types that do not extend
> {{AbstractSslContextFactory}} as unsupported.
> Document the contract for custom factories: an overridden {{create()}} must
> obtain the context from {{super.create()}} on every call. The key and trust
> loading hooks must read fresh material for their changes to take effect.
> Trust managers supplied through {{setTrustManagers()}} are reused.
> h3. Operator instructions
> Update “Upgrading Certificates” in the SSL/TLS guide: prepare peer trust
> across the cluster, replace stores at the configured paths with the same
> passwords, run reload and verify a new connection. To recover from a bad
> replacement, restore the previous files and reload again. Changing node
> configuration requires a restart.
> h3. Done when
> The control utility applies a replacement on servers and thick clients, and a
> new connection confirms it. Tests cover shared and custom factories,
> concurrent reloads of the same factory, confirmation, permissions and logs.
> Tests verify that an unsupported factory prevents all reloads on its node,
> and that a failed reload prevents later reloads there. The report retains
> results from other nodes. A listener that did not start must not appear as
> reloaded; a node with no TCP transports using TLS must still appear.
> Depends on IGNITE-29256. This ticket adds the command and its documentation,
> not a separate status command, new certificate-date checks or background
> monitoring.
> [Implementation plan in PR #13785|https://github.com/apache/ignite/pull/13785]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
