[
https://issues.apache.org/jira/browse/IGNITE-29210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29210:
--------------------------------------
Description:
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 the topology, while preserving the
full report.
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]
was:
Let administrators load replacement TLS keys and trust on running nodes with
{{control.sh --ssl reload}}. IGNITE-29256 makes new TCP connections use the
factory's current context.
h3. Command behavior
# Run on all server and thick-client nodes in the current topology. Include TCP
discovery, communication, the client connector and binary REST where they
started with TLS. If transports share a factory, reload it once per node.
# Require {{ADMIN_OPS}}. Ask for confirmation unless the administrator passes
{{--yes}}.
# Report each node and transport, including nodes with no TLS. Each node logs
its outcome and, when security is enabled, the initiator.
# Continue after individual failures and keep successful replacements in use.
Exit with an error if a target fails, is unsupported or leaves the topology.
h3. Factory behavior
Make {{AbstractSslContextFactory.init()}} public. Reloads of the same factory
run one at a time. Cached {{create()}} calls can return the current context
during loading.
Reload factories that extend {{AbstractSslContextFactory}}. Report other
factory types as unsupported. An override of {{create()}} must get the context
from {{super.create()}} on every call to see a reload. The
{{createKeyManagers()}} and {{createTrustManagers()}} hooks must load fresh
material for their changes to take effect.
h3. Administrator guide
Update “Upgrading Certificates” in the SSL/TLS guide. Explain how to prepare
peer trust across the cluster, replace stores at the configured paths using the
same passwords, and verify the result with a new connection. To recover,
restore the previous files and run reload again. The factory reuses trust
managers supplied through {{setTrustManagers()}}. Changing node configuration
requires a restart.
h3. Acceptance
Verify rotation with a new connection on a server and a thick client. Cover
shared and custom factories, concurrent commands, confirmation, permissions and
outcome logging. Check mixed results, unsupported and departed targets, nodes
with no TLS, and a transport that did not start.
Depends on IGNITE-29256. A separate status command, new certificate-date checks
and background monitoring are outside this ticket.
[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: 1h 10m
> Remaining Estimate: 0h
>
> 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 the topology, while preserving
> the full report.
> 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]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
