[
https://issues.apache.org/jira/browse/IGNITE-29210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignite TC Bot updated IGNITE-29210:
-----------------------------------
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> 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: 5h 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)
