[
https://issues.apache.org/jira/browse/IGNITE-28867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-28867:
--------------------------------------
Description:
Allow administrators to replace TLS certificates and trust stores without
restarting the cluster, and support automatic renewal when certificates are
supplied by an external system.
The implementation in PR #13335 is being split into smaller changes for review
and merge. Keep that branch as the reference while the subtasks are extracted.
Each subtask must include its tests and documentation and work when merged on
its own prerequisites.
Planned merge order:
# IGNITE-29208 — Preserve SSLEngine peer host and port in SSLContextWrapper.
Independent bug fix.
# IGNITE-29209 — Add fresh SSL context creation and certificate metadata,
preserving the existing factory hooks.
# IGNITE-29210 — Deliver manual reload and status for discovery, communication,
the client connector, and binary REST, with authorization and audit.
# IGNITE-29211 — Add automatic renewal, retries after expiry, and the single
node metric ssl.ConsecutiveRenewalFailures.
# IGNITE-29212 — Add HTTP REST integration and migration from Jetty XML.
IGNITE-29209 is required by IGNITE-29210. Automatic renewal and HTTP REST both
require IGNITE-29210, but are independent of each other. The peer-address fix
is first in the merge order because it touches the same wrapper, not because
the later features require it.
Keep the design based on one context per factory instance. Transports sharing a
factory reload together. Reload validates available certificate metadata and
supported TLS settings, but does not test connections or peer trust.
Certificate rollout and verification remain the administrator's responsibility.
Close this umbrella after all parts are merged and the assembled solution
passes the relevant SSL tests, including mutual TLS and compatibility with
existing configurations. Include test helpers and documentation with the
feature that needs them.
Reference implementation: https://github.com/apache/ignite/pull/13335
was:
Currently, Ignite node TLS certificates are loaded only once during node
startup and then used to establish secure connections between `node to node`,
`node to thin client`. As a result, updating a certificate requires restarting
the Ignite node, causing unnecessary downtime and requiring additional
administrative effort.
We need to implement hot redeployment of TLS certificates, allowing the Ignite
node to reload the certificates at runtime without requiring a node restart.
Existing TLS sessions should remain unaffected, while all new TLS handshakes
should use the updated credentials.
Basic Steps
1. Introduce a mechanism to trigger certificate reloading (for example, through
`control.sh`).
2. Create a new `SslContext` instance by invoking `SslContextFactory`.
3. Replace the active `SslContext` used for TLS connection establishment. All
newly established connections must use the updated certificates, while existing
connections will continue to operate without interruption.
h2. Design
The pull request describes the design in full:
https://github.com/apache/ignite/pull/13335. In short:
*Commands.* {{control.sh --ssl reload}} is run against any node and reaches
every node of the cluster, servers and clients. Each node asks its own SSL
context factories for new contexts, so the command carries no certificate and
no path. {{control.sh --ssl status}} reports the certificate every node serves
and the result of its last reload.
*Discovery.* The listening socket is now a plain {{ServerSocket}}, and every
accepted connection is wrapped with the context current at that moment. An
{{SSLServerSocket}} captures the context at bind time, which would have left
discovery reloadable for outbound connections only.
*Automatic renewal.* Optional and off by default: with {{renewalEnabled}} set
on the SSL context factory, a node reads its stores again when
{{renewBeforeFraction}} of the certificate lifetime is left, with the same
checks.
*Check before applying.* A rebuilt context goes in use only if every
certificate of its chain is valid now, and it presents a certificate whenever
the context in use does. If the factory serves discovery or communication, the
node's own trust store must also accept the new certificate; the node checks
this with a TLS handshake in memory and asks no other node. Otherwise the node
keeps its current certificates, and the command reports the reason for that
node.
h2. Why the context is replaced rather than the key managers
The alternative is to keep one {{SSLContext}} and swap the delegates inside
{{X509ExtendedKeyManager}}/{{X509ExtendedTrustManager}}. Elasticsearch had
exactly that and removed it in elastic/elasticsearch#30509 for FIPS 140-2,
where only SunJSSE managers may be used; Jetty and Kafka also rebuild the
context. Swapping managers additionally keeps the session cache and ticket keys
of the old context, so a resumed session is still served the old certificate
and trust cannot be revoked by a reload.
> [Umbrella] TLS certificate reload and automatic renewal
> -------------------------------------------------------
>
> Key: IGNITE-28867
> URL: https://issues.apache.org/jira/browse/IGNITE-28867
> Project: Ignite
> Issue Type: Task
> Reporter: Mikhail Petrov
> Assignee: Anton Vinogradov
> Priority: Major
> Labels: ise
> Fix For: 2.19
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> Allow administrators to replace TLS certificates and trust stores without
> restarting the cluster, and support automatic renewal when certificates are
> supplied by an external system.
> The implementation in PR #13335 is being split into smaller changes for
> review and merge. Keep that branch as the reference while the subtasks are
> extracted. Each subtask must include its tests and documentation and work
> when merged on its own prerequisites.
> Planned merge order:
> # IGNITE-29208 — Preserve SSLEngine peer host and port in SSLContextWrapper.
> Independent bug fix.
> # IGNITE-29209 — Add fresh SSL context creation and certificate metadata,
> preserving the existing factory hooks.
> # IGNITE-29210 — Deliver manual reload and status for discovery,
> communication, the client connector, and binary REST, with authorization and
> audit.
> # IGNITE-29211 — Add automatic renewal, retries after expiry, and the single
> node metric ssl.ConsecutiveRenewalFailures.
> # IGNITE-29212 — Add HTTP REST integration and migration from Jetty XML.
> IGNITE-29209 is required by IGNITE-29210. Automatic renewal and HTTP REST
> both require IGNITE-29210, but are independent of each other. The
> peer-address fix is first in the merge order because it touches the same
> wrapper, not because the later features require it.
> Keep the design based on one context per factory instance. Transports sharing
> a factory reload together. Reload validates available certificate metadata
> and supported TLS settings, but does not test connections or peer trust.
> Certificate rollout and verification remain the administrator's
> responsibility.
> Close this umbrella after all parts are merged and the assembled solution
> passes the relevant SSL tests, including mutual TLS and compatibility with
> existing configurations. Include test helpers and documentation with the
> feature that needs them.
> Reference implementation: https://github.com/apache/ignite/pull/13335
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
