Fix NiFi 2 clustering
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 15/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- kubernetes
Direzione di ricerca
Inizia analizzando la condivisione dello stato e il comportamento di JWT a livello di cluster in NiFi 2, incluso il modo in cui viene generata la chiave di firma e il modo in cui vengono utilizzati i controlli del nome host SNI. Esamina anche il percorso di autenticazione di metrics. Il lavoro è completato quando i token emessi dal cluster funzionano su qualsiasi nodo senza sessioni sticky e le modifiche proposte per SNI e metrics sono state valutate.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Description
Currently, if you create a JWT token for a nifi node, you can only log into this specific node. This is apparently by design as explained in https://issues.apache.org/jira/browse/NIFI-7246.
The problem with this is that it forces sticky sessions (when using a load balancer) which defeats the purpose of using a stateless token.
This appears to exist because some NiFi state is not shares, so for some API calls you currently must connect to the applicable node.
Slightly relevant is that there are SNI checks (so that the server can verify that the client is connecting via the expected hostname). Presumably this was implemented due to the previously mentioned requirement for connecting to the correct node.
Proposed Solution
[!TIP]
As this is a specific problem of the product NiFi we think it might be useful to fix it upstream.
There are multiple parts to the overall solution:
- Fix NiFi 2's state sharing so that there is no longer a need to send requests to a specific node.
- Allow JWTs to be issued by a cluster wide issuer for a single audience so that the same token can be used on any node (thereby removing the need for sticky sessions).
- Additional nice-to-have's:
- Remove the SNI hostname check (assuming it was only there as a protection mechanism for what was mentioned in the Description section).
- Possibly remove authentication from metrics endpoints (and ideally run metrics on a different http server).
Unknowns
- How is the JWT signing key currently generated?
- Can the SNI check be removed once it doesn't matter which cluster node is connected to?
- Lingua principale
- Rust
- Stelle
- 48
- Fork
- 12
- Merge medio
- 11h 26m
- PR unite (30g)
- 10
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di stackabletech/nifi-operator
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
stackabletech/nifi-operator#956 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
stackabletech/nifi-operator#879 ·
-
customer-request type/bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 42/100
stackabletech/nifi-operator#842 · 1 commento ·
-
size/M type/security
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
stackabletech/nifi-operator#811 · 1 commento ·
-
size/L
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
stackabletech/nifi-operator#810 · 1 commento ·
Tutte le issue di stackabletech/nifi-operator
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
agentic-workflows
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
web-infra-dev/rspack#15847 ·