SCRAM credentials

Under Kafka ▸ Service Accounts, a user's SCRAM credentials tab stores the SASL/SCRAM passwords it signs in with, and never shows one back. The cluster keeps each credential; BROKA sends the password once, for the cluster to salt and hash, and keeps nothing. The same user's ACL rules are on the same page, described in Service accounts and ACLs.

Which user the tab is for

The tab is one of four on a service account's page, and every credential it stores is for that page's user name. The Service Accounts list is drawn from the cluster's ACL rules, so a user that no rule names yet is not on it: New ACL opens the page for any name you give it, with all four tabs.

What the tab lists

Each row is one credential: its Mechanism — SCRAM-SHA-256 or SCRAM-SHA-512 — and the Iterations it was stored with. That is all the cluster returns, and all there is to show: no password comes back, in any form. A user holds at most one credential per mechanism, so the table has at most two rows; a user with none reads No SCRAM credentials.

Adding a credential or changing a password

Add credential opens Add SCRAM credential for a mechanism the user does not hold yet — the Mechanism list offers only those. When the user holds both, the button is disabled with This user holds both mechanisms; change a password on its row. A row's pencil opens Change SCRAM-SHA-512 password (or 256) with the mechanism fixed.

• Iterations — left empty, the mechanism's minimum, 4096. It must be a whole number greater than zero, and a count the cluster will not accept is refused with the cluster's own sentence.
• Password — New password when changing one. It is required.

The password is never shown back

The password is typed once and sent once. The dialog drops it the moment the request leaves, whatever the answer; BROKA passes it through in that one request, Kafka's client library salts and hashes it, and its bytes are overwritten as the call returns. It is in no response, no log line and no audit event, and the dialog says so under the field: Sent once for the cluster to salt. It is never stored here, never returned, and never recorded in the audit trail.

Nothing can show a password later, because nothing on BROKA's side has it. A forgotten password is replaced from the row's pencil, not read.

Deleting a credential

A row's delete icon asks Delete the SCRAM-SHA-512 credential of svc-ledger? The user can no longer sign in with that mechanism, the deletion cannot be undone, and a new credential needs a new password. The confirmation asks for a reason, in every environment.

Storing a credential does not turn SCRAM on

Which mechanisms a listener accepts is the brokers' own sasl.enabled.mechanisms, set in their configuration. Storing a credential here gives a user something to sign in with; it does not enable SCRAM on any listener.

What the tab needs

The tab needs Kafka 2.7 or later. On a KRaft cluster, storing and deleting credentials also need a metadata version that keeps them, metadata.version 3.5-IV2 — see Metadata quorum and features. Where either is missing, the tab says why in a banner and its buttons are shown disabled with that reason, which names the version needed and the one detected.

Storing and deleting a credential need the permission to manage the cluster. In a read-only environment the buttons are disabled with the environment's reason. The connection's Kafka identity must also be allowed to describe the cluster to read credentials, and to alter it to store or delete one; where it may not, the tab says so and the buttons are disabled with that reason.

Recorded

Storing a credential is recorded with its mechanism and iterations — the first a user holds as the user's creation, any later one as an update — and the event says only that the password changed, never what it is. Deleting one is recorded with its mechanism and your reason; deleting a user's last credential is recorded as the user's deletion.

In Commercial, reading a user's credentials is recorded too, like reading the ACLs, and the record holds mechanisms and iterations only. BROKA keeps no copy of a credential: it is read from the cluster each time, and the audit entry is the only lasting record on BROKA's side.