villebro opened a new pull request, #45379: URL: https://github.com/apache/superset/pull/45379
### SUMMARY Follow-up to #45355. With Redis/Valkey Sentinel, TLS to the resolved master is supported, but the connections to the sentinel nodes themselves were always plaintext, on both the Python coordination backend and the WebSocket server. A deployment whose sentinels only accept TLS therefore could not be used. This adds an opt-in setting on both sides, with the same semantics: - **Python (`RedisSentinelCacheBackend`):** new `CACHE_REDIS_SENTINEL_SSL` (default `False`). When set, the sentinel-node connections use TLS with the same `CACHE_REDIS_SSL_CERTFILE`, `CACHE_REDIS_SSL_KEYFILE`, `CACHE_REDIS_SSL_CERT_REQS` and `CACHE_REDIS_SSL_CA_CERTS` settings as the master. `CACHE_REDIS_SSL` continues to control the master connection only, so a TLS-only deployment sets both. It is picked up wherever the backend is built from config, including the semantic-cache private clients. - **WebSocket server:** new `sentinelSsl` / `REDIS_SENTINEL_SSL` (default `false`), wired to ioredis's `sentinelTLS`, reusing the existing `ssl*` settings. As before, `ssl` secures the master and ioredis needs `enableTLSForSentinelMode` for that, which is already set. - **Docs:** `cache.mdx` documents the new key and the WebSocket counterpart. It also notes that other caches using `CACHE_TYPE: RedisSentinelCache` (e.g. `CACHE_CONFIG`) are built by Flask-Caching, which already forwards `sentinel_`-prefixed `CACHE_OPTIONS` (such as `sentinel_ssl`) to the sentinel-node connections, so no Superset change is needed there. Defaults are unchanged, so existing deployments (including TLS master with plaintext sentinels) behave as before. Celery broker/result-backend Sentinel settings are configured directly through Celery/kombu transport options and are not touched here. ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF N/A ### TESTING INSTRUCTIONS - Python: `pytest tests/unit_tests/coordination/test_cache_backend.py`. The new tests build a real `RedisSentinelCacheBackend` (no network needed, since connections are lazy) and assert the connection classes and TLS kwargs on the sentinel-node pools and the master pool, plus `from_config` reading `CACHE_REDIS_SENTINEL_SSL`. - WebSocket: `cd superset-websocket && npm test`. - Manual (not yet done): run against a Sentinel deployment where the master and sentinels require TLS, with `CACHE_REDIS_SSL`/`CACHE_REDIS_SENTINEL_SSL` set in `DISTRIBUTED_COORDINATION_CONFIG` and `REDIS_SSL`/`REDIS_SENTINEL_SSL` on the WebSocket server, and confirm `/ready` returns 200 and realtime messages are delivered. ### ADDITIONAL INFORMATION - [ ] Has associated issue: - [ ] Required feature flags: - [ ] Changes UI - [ ] Includes DB Migration (follow approval process in [SIP-59](https://github.com/apache/superset/issues/13351)) - [ ] Migration is atomic, supports rollback & is backwards-compatible - [ ] Confirm DB migration upgrade and downgrade tested - [ ] Runtime estimates and downtime expectations provided - [x] Introduces new feature or API - [ ] Removes existing feature or API -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
