[
https://issues.apache.org/jira/browse/IGNITE-28867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131199#comment-18131199
]
Anton Vinogradov commented on IGNITE-28867:
-------------------------------------------
[Ignite PR Checker|https://ignite-pr-checker.is-a.dev/?pr=13335] verdict for PR
13335 · RunAll build [9437567|https://ci2.ignite.apache.org/build/9437567] ·
tested
[d47deb2|https://github.com/apache/ignite/pull/13335/commits/d47deb2e10bcad292374c0f133351c3cb7d077bf]
· 149 suites ran, 0 reused
(!) *This run doesn't cover the PR fully:*
- 46 suites ran fewer tests than the same suites on master
Everything below is what it did manage to say.
(?) *46 suites ran fewer tests than on master* (tests that never ran can't
fail):
- Queries 6: ran 70 of master's 984 tests (*-93%*)
- Cache (Failover) 1: ran 26 of master's 36 tests (*-28%*)
- Examples: ran 84 of master's 114 tests (*-26%*)
- Cache (Deadlock Detection): ran 33 of master's 44 tests (*-25%*)
- JTA: ran 34 of master's 45 tests (*-24%*)
- Cache 20: ran 215 of master's 276 tests (*-22%*)
- Cache 10: ran 345 of master's 437 tests (*-21%*)
- Cache (Failover) 4: ran 38 of master's 48 tests (*-21%*)
- Cache (Failover) 5: ran 67 of master's 85 tests (*-21%*)
- Compute (Affinity Run): ran 23 of master's 29 tests (*-21%*)
- SPI (URI Deploy): ran 55 of master's 69 tests (*-20%*)
- Cache (Expiry Policy): ran 136 of master's 171 tests (*-20%*)
- Cache 16: ran 319 of master's 395 tests (*-19%*)
- Cache 21: ran 209 of master's 258 tests (*-19%*)
- Basic 3: ran 165 of master's 202 tests (*-18%*)
- Cache 14: ran 193 of master's 233 tests (*-17%*)
- NUMA Allocator: ran 17 of master's 20 tests (*-15%*)
- Cache 11: ran 162 of master's 191 tests (*-15%*)
- Activate / Deactivate Cluster: ran 227 of master's 266 tests (*-15%*)
- Cache 2: ran 424 of master's 499 tests (*-15%*)
- PDS (Indexing): ran 206 of master's 242 tests (*-15%*)
- Cache 7: ran 147 of master's 171 tests (*-14%*)
- PDS 10: ran 216 of master's 251 tests (*-14%*)
- Disk Page Compressions 8: ran 216 of master's 251 tests (*-14%*)
- Cache 18: ran 152 of master's 176 tests (*-14%*)
- Cache 3: ran 519 of master's 606 tests (*-14%*)
- Cache 6: ran 170 of master's 197 tests (*-14%*)
- Data Structures: ran 349 of master's 406 tests (*-14%*)
- Queries (Config Variations): ran 288 of master's 336 tests (*-14%*)
- Cache 9: ran 79 of master's 91 tests (*-13%*)
- PDS 8: ran 249 of master's 285 tests (*-13%*)
- SPI (Discovery) 2: ran 296 of master's 340 tests (*-13%*)
- Dev Utils: ran 29 of master's 33 tests (*-12%*)
- Calcite SQL 2: ran 1239 of master's 1406 tests (*-12%*)
- PDS (Indexing) 2: ran 200 of master's 227 tests (*-12%*)
- Cache (Tx Recovery): ran 93 of master's 106 tests (*-12%*)
- PDS 4: ran 213 of master's 239 tests (*-11%*)
- Service Grid: ran 401 of master's 451 tests (*-11%*)
- Thin Client: Java: ran 443 of master's 495 tests (*-11%*)
- Basic 4: ran 710 of master's 796 tests (*-11%*)
- SPI (Discovery): ran 282 of master's 317 tests (*-11%*)
- Web Sessions: ran 54 of master's 60 tests (*-10%*)
- Queries 3: ran 1499 of master's 1671 tests (*-10%*)
- Disk Page Compressions 6: ran 117 of master's 130 tests (*-10%*)
- Cache 4: ran 599 of master's 665 tests (*-10%*)
- PDS (Unit Tests): ran 37 of master's 41 tests (*-10%*)
(?) *No blockers found — but the run above can't prove the PR is clean.* 24
failing tests are not blamed on this PR. Re-run after you handle what is listed
above.
_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 1 auto re-run wave: #1 — 3 suites that failed mid-run.
> 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: 6h 40m
> 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
(v10.3.26#10030026)
