Skip to content

Update ACL rules for Replication #457

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
hieu2102 wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Update ACL rules for Replication #457

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1fc34e9
update ACL rules for atomic slot migration
hieu2102 Jul 15, 2026
4351bf9
add sync permission
hieu2102 Aug 11, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions topics/acl.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -654,11 +654,14 @@ Sentinel does not need to access any key in the database but does use Pub/Sub, s

Valkey replicas require the following commands to be allowed on the primary instance:

* PSYNC, REPLCONF, PING
* SYNC, PSYNC, REPLCONF, PING

For cluster deployments, Valkey 9.0 introduces the Atomic Slot Migration feature, which requires the replication user to be allowed to run `CLUSTER SYNCSLOTS`.
No keys need to be accessed, so this translates to the following rules:
For cluster deployments, Valkey 9.0 introduces the Atomic Slot Migration feature, which requires additional permissions:

ACL setuser replica-user on >somepassword +psync +replconf +ping +cluster|syncslots
* CLUSTER SYNCSLOTS, @write, SELECT

This translate to the following rules:

ACL setuser replica-user on >somepassword +sync +psync +replconf +ping +cluster|syncslots +@write +select ~*

Note that you don't need to configure the replicas to allow the primary to be able to execute any set of commands. The primary is always authenticated as the root user from the point of view of replicas.
Loading