[
https://issues.apache.org/jira/browse/IGNITE-28867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18128020#comment-18128020
]
Anton Vinogradov commented on IGNITE-28867:
-------------------------------------------
[Ignite PR Checker|https://ignite-pr-checker.is-a.dev/?pr=13335] verdict for PR
13335 · RunAll build [9416996|https://ci2.ignite.apache.org/build/9416996] ·
tested
[c68507f|https://github.com/apache/ignite/pull/13335/commits/c68507f943b531d0b59b7dc442573c6b546661d8]
· 147 suites ran, 0 reused
(!) *3 test(s) started failing on this code* — not proven blockers yet: too few
runs of this revision to tell a break from a flake, so a re-run of the suite
decides it.
- Thin client: Python · {{test_examples}} — 3 tests (1 run):
{{test_examples(/data/tcAgent/work/425d7af4e9aa99d9/ignite-python-thin-client/tests/__/examples/read_binary_py)}},
{{test_examples(/data/tcAgent/work/425d7af4e9aa99d9/ignite-python-thin-client/tests/__/examples/sql_py)}},
{{test_examples(/data/tcAgent/work/425d7af4e9aa99d9/ignite-python-thin-client/tests/__/examples/async_sql_py)}}
·
[TC|https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_WiPThinClientPython/9417323?buildTab=tests]
(x) *29 blocker(s) in 1 suite(s):*
- Thin client: Python · {{test_sql}} — 17 tests: {{test_sql(1)}},
{{test_sql(3)}}, {{test_sql(5)}} and 14 more ·
[TC|https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_WiPThinClientPython/9417327?buildTab=tests]
- Thin client: Python · {{test_datatypes}} — 6 tests:
{{test_uuid_representation(d57babad-7bc1-4c82-9f9c-e72841b92a85)}},
{{test_uuid_representation(5946c0c0-2b76-479d-8694-a2e64a3968da)}},
{{test_uuid_representation(a521723d-ad5d-46a6-94ad-300f850ef704)}} and 3 more ·
[TC|https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_WiPThinClientPython/9417327?buildTab=tests]
- Thin client: Python · {{test_sql_composite_key}} — 4 tests:
{{test_sql_composite_key(InsertMode_SQL)}},
{{test_sql_composite_key(InsertMode_CACHE)}},
{{test_sql_composite_key_async(InsertMode_SQL)}} and 1 more ·
[TC|https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_WiPThinClientPython/9417327?buildTab=tests]
- Thin client: Python · {{test_binary}} — 2 tests: {{test_sql_read_as_binary}},
{{test_sql_read_as_binary_async}} ·
[TC|https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_WiPThinClientPython/9417327?buildTab=tests]
_1 run: only one failure on this branch backs it: a re-run of its suite
confirms or clears it._
_What each label means and what to do: [verdict
glossary|https://github.com/anton-vinogradov/ignite-pr-checker/blob/main/docs/features.md#verdict-glossary]._
♻️ Settled after 2 auto re-run wave(s): #1 — 3 suites that failed mid-run; #2 —
1 watch + 1 broken suite(s).
> Add control.sh --ssl commands for TLS certificate hot redeployment
> ------------------------------------------------------------------
>
> 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: 5h 10m
> Remaining Estimate: 0h
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
