Tracking: Support Redis ACL

Aperta
  • Qualcosa non va?
#3,518 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
cpp, redis
Ambito
authentication, authorization, databases, distributed-systems, security

Direzione di ricerca

Inizia con la semantica delle ACL e il modello dei namespace in #3517, quindi esamina i punti di ingresso proposti: regole ACL SETUSER, AUTH, HELLO AUTH, persistenza, replica ed estrazione delle chiavi dei comandi. Il lavoro è completo quando gli utenti ACL possono essere gestiti, autenticati, associati a un namespace, resi persistenti e replicati, con l’applicazione delle restrizioni sui comandi e sulle chiavi e test di integrazione che coprano i percorsi di successo e di rifiuto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement tracking-issue
Motivation

Kvrocks currently supports authentication through requirepass and namespace tokens, but it does not support Redis ACL users or fine-grained permission control.

This is something the Kvrocks community has needed for a long time and is eager to have.

This limits Redis compatibility and makes some production scenarios hard to secure, especially:

  • read-only replication users
  • command-level restrictions
  • key-pattern restrictions
  • per-user password management
  • Redis client compatibility with ACL-aware workflows

Related discussions and issues:

Scope

This tracking issue splits Redis ACL support into smaller sub-issues. The initial goal is not to support every Redis ACL edge case at once, but to build a maintainable foundation that can evolve safely.

High-Level Design Direction
  • ACL users are managed by the admin user.
  • Each ACL user maps to exactly one Kvrocks namespace.
  • ACL data is persisted in storage instead of an external ACL file, so it can participate in replication.
  • ACL rules are stored in a Redis-compatible ACL SETUSER rule-string form where practical.
  • Runtime permission checks use parsed/cached ACL user objects.
  • Command permissions should support command names, categories, and subcommands.
  • Key/channel permissions should be enforced through the existing command key extraction path where possible.
Initial Non-Goals
  • Do not support deprecated Redis first-argument ACL rules.
  • Do not require a full ACL file implementation in the first phase.
  • Do not refactor every command family before the ACL foundation lands.
  • Do not change public command behavior unrelated to ACL.
Recommended implementation steps
  • Finalize ACL semantics and namespace model
  • https://github.com/apache/kvrocks/issues/3517
  • Add ACL user model, parser, serializer, and in-memory cache
  • Persist and replicate ACL users
  • Integrate ACL authentication with AUTH and HELLO AUTH
  • Add command and category permission checking
  • Add key and channel pattern permission checking
  • Implement the initial ACL command set
  • Add ACL denial logging and ACL DRYRUN
  • Add integration tests against Redis ACL-compatible behavior
  • Add documentation and migration notes
Acceptance Criteria
  • Kvrocks can create, update, delete, and inspect ACL users.
  • A non-admin ACL user can authenticate and is bound to the intended namespace.
  • Command/category restrictions are enforced before command execution.
  • Key-pattern restrictions are enforced for commands with known key specs.
  • Replication can use a restricted ACL user where the required commands are allowed.
  • ACL metadata is replicated consistently to replicas.
  • Redis client workflows using HELLO ... AUTH default <password> remain compatible.
  • Tests cover success and denial paths for authentication, command permissions, key permissions, and replication-sensitive cases.
Lingua principale
C++
Stelle
4.5k
Fork
686
Merge medio
2g 13h
PR unite (30g)
40

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/kvrocks

Tutte le issue di apache/kvrocks

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.