[
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.
# 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]
was:
After IGNITE-29256, factories can reload TLS material and new TCP connections
can use it. 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 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 without 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 node leaving after its response does not change that result.
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
commands, 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 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: 2h 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.
> # 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]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
