ACL users and the security log

These are Redis's own users, read from the server and written back to it. BROKA keeps no copy of them, mirrors nothing into its database, and is not a second place where access can drift out of step with the server.

The user list

Each user shows its state, how many passwords it has, and its key, channel and command rules — plus the selectors, where the server supports them.

The identity BROKA itself connects as is badged, because removing its grants would take every Redis screen down with them. Neither it nor the default user can be deleted, in the console or through the API: their rows have no delete button, and the server refuses both.

Passwords are counted, never shown

A user's passwords are stored by Redis as hashes and BROKA drops them on the way through. What the list shows is how many there are.

Two of those counts are findings rather than settings, and the console marks them as such:

• nopass — any password is accepted for this user. That is not a configuration choice with trade-offs; on a reachable Redis it is an open door.
• No password set at all, which usually means the account was created and never finished.

Rules are text, in Redis's own syntax

Rules are edited as lines in the syntax Redis itself uses — on, >password, ~key:*, &channel, +@read, -@dangerous.

This is deliberate rather than lazy. Redis's ACL grammar gains capabilities between versions, and a form that modelled it would silently drop whatever this build had not heard of — including, on save, grants the user already had. Text passes through what it does not understand.

For the same reason, the category chips come from your server, not from a list compiled into BROKA. A category your Redis knows about and this build does not still appears, and clicking it appends the rule to the box.

Saving is declarative. BROKA resets the user and applies exactly the lines you left in the box, so deleting a line removes that grant. A merge would make it impossible to take a permission away, which is the operation you most need to be sure about.

Passwords are the one exception, and the dialog says so. Saving without a >password line keeps the passwords the user already has. To replace them, write a new one; to remove them, write nopass.

BROKA does not validate the rules — Redis does, and its error is what you see. There is one grammar, and it belongs to the server.

Generate password asks the server for a new random password and appends it to the box as a >password rule, so it is saved with the others. Copy it from the box before you save: it is shown this once, is never read back, and is never written to the audit trail.

Testing a command before anyone tries it

An existing user's dialog has Test a command: type a command with its arguments — get cache:1 — and the server answers whether this user may run it, and if not, why. Nothing is executed. It tests the rules saved on the server, not the edits in the box above it, because the server has no other copy to evaluate; the hint says so, so that an unsaved edit does not look tested. A test is recorded as a privileged read. On a server without this check it is shown greyed out, with the reason.

On a Redis Cluster these belong to each node

ACL users and the security log are kept per node, so on a cluster BROKA shows them and refuses to change them, rather than changing the one node it happens to reach.

Deleting a user disconnects it

Removing an ACL user does not only close the account. Redis closes every connection already authenticated as that user, so an application using it is disconnected the moment you apply the change — not at its next reconnect.

The confirmation says so, because "delete the user" and "disconnect the workers" are the same action here and only one of them is in the button's name.

The security log

Redis keeps a record of the requests it refused, and this is the only record of an authorisation failure that exists — BROKA cannot reconstruct one from anywhere else.

Each entry names who was refused, why — a command they may not run, a key outside their pattern, a channel, or a failed authentication — what they asked for, and where it came from. Entries that repeat are coalesced with a count.

An empty log is not evidence of no denials. Redis keeps a bounded number of these in memory and loses them on restart, and the empty state says exactly that rather than reading as an all-clear. It is the difference between nothing was refused and nothing is still in the buffer.

The log can be cleared on a single server, which is itself a recorded action. On a cluster it is refused, for the reason above.

Who may, and what asks why

New user, each user's edit and delete controls and Clear the log appear only where you may write to the connection; a read-only environment or a connection frozen with its own read-only switch refuses them. All three writes ask for a reason in every environment — deleting a user and clearing the log in their confirmation, saving a user's rules in a reason window once you press Create user or Save rules. A connection whose identity may not run the ACL commands sees a notice saying so instead of the list; that is a normal least-privilege deployment, and the fix is a grant on the Redis side.