Zhihui Cloud Redis ACL: Multi-Account Access Control with Valkey 7.2+

Introduction

Zhihui Cloud Redis now provides ACL (Access Control List) multi-account management built on Valkey 7.2 and above. This feature allows a single Redis instance to host multiple independent accounts, each with its own password and either read-write or read-only permissions, while preserving the original default account for compatibility with existing workloads.

Background: Problems with the Shared Default Account

Traditionally, a Redis instance uses a single default account and one password shared by all business applications. As the number of businesses grows, this model creates several issues:

Account sharing across teams

Overly broad permissions (every client has full read-write access)

Large blast radius when rotating passwords — every client must be updated simultaneously

1. ACL Technical Principles

ACL binds each incoming connection to a specific user identity and then evaluates a set of rules to decide whether a command is allowed. In Valkey 7.2+, ACL rules can control:

Command permissions (individual commands or categories like @read, @write)

Key access patterns (e.g., ~*, ~app:*)

Pub/Sub channel patterns (e.g., &channel:*)

Logical database access (supported since Redis 7.2)

The client connection processing chain is illustrated in the diagram below:

ACL Rule Dimensions

User status — on / off controls whether the account can log in

Password — >password sets the authentication credential

Commands — +GET, +@read, +@write define allowed commands or command groups

Keys — ~*, ~app:* restrict the key namespace the account may touch

Channels — &channel:* limit Pub/Sub channel access

Database — Redis 7.2 adds rules to constrain which logical databases are accessible

Example Role Definitions

username_rw
└── allows read and write commands required by the business

username_ro
└── allows read commands, denies write commands

default
└── retains original authentication method for legacy workloads

Valkey adopts a default-deny model: a newly created ACL user has no permissions until explicitly enabled and granted a password, command rights, and data-access rules. The ACL SETUSER command modifies existing users incrementally, so centralized platform management of account rules prevents permission drift caused by manual changes.

For developers, ACL verification happens on the Valkey server; applications still use the standard Redis protocol and only need to add a username to the connection parameters. For operators, accounts, passwords, and permissions become independent objects that can be created, reset, and revoked separately, shrinking the impact radius of failures or security incidents.

2. Multi-Account, Independent Passwords, On-Demand Authorization

Zhihui Cloud Redis currently offers three account types:

default — read-write; supports GET, SET, HGET, HSET, LPUSH, SADD, ZADD, EXPIRE …; used for backward compatibility

ACL read-write account — read-write; same command set as default; intended for online business workloads

ACL read-only account — read-only; allows GET, HGET, ZRANGE but denies SET, DEL, HSET; suited for data querying, analysis, troubleshooting, and read-only tools

Typical Deployment Topology

Redis (Valkey 9.1) instance
      │
      ├── default      → legacy workloads
      ├── username_rw  → Business A / Business B read-write
      ├── username_ro  → data analysis, ad-hoc queries
      └── username_ro1 → business platform read-only

Existing workloads continue using the default account with the original host + port + password connection string — no changes required. New workloads should prefer dedicated ACL accounts: each business gets its own username, password, and permission set; query-oriented scenarios use read-only accounts to avoid unnecessary write privileges.

Password Rotation Blast Radius Reduction

In the traditional model, multiple businesses share the default password:

Business A ─┐
Business B ─┼── default password
Business C ─┘

With ACL, each business has its own account and password:

Business A → account_a → password_a
Business B → account_b → password_b
Business C → account_c → password_c

If Business A needs to rotate its password, only account_a is affected:

Business B is unaffected

Business C is unaffected

The default account is unaffected

3. Permission Management Optimized for Developers and Operators

For Developers

Different businesses use independent accounts, eliminating shared Redis passwords.

Query and analysis programs can use read-only accounts, reducing accidental writes or deletes.

Password changes for one business do not require coordinated updates across other businesses.

Connection change is minimal — just add the username parameter.

Example redis-cli connection with an ACL account:

redis-cli -h redis.example.com -p 6379 --user username_rw -a 'password'

For Operators

Accounts map 1:1 with businesses, making permission boundaries explicit.

Read-write or read-only roles can be assigned per scenario, avoiding long-lived high-privilege credentials.

Single-account password resets shrink the blast radius of credential rotation and account changes.

Account lifecycle (create, fetch password, reset password, delete) is managed entirely through the Zhihui Cloud console; businesses never need to run ACL SETUSER, ACL DELUSER, or ACL LIST directly.

Recommended Usage Scenarios

Existing business, no isolation needed → continue using default New online business → ACL read-write account

Query, analysis, troubleshooting → ACL read-only account

Multiple businesses sharing one instance → each business gets an independent ACL account

Need independent password rotation → ACL independent account

High-security production workloads → prefer ACL

New Businesses Should Adopt ACL Accounts

The article contrasts the traditional shared-password model with the ACL model via architecture diagrams (included as images). In the ACL model, every business owns a distinct tuple of username, password, and permissions, removing the need for multiple teams to share a single Redis/Valkey secret.

4. Core Value of Zhihui Cloud Redis ACL

Compatibility: default account remains, legacy workloads require no migration.

Permission isolation: Read-write and read-only roles match actual business needs.

Account independence: Each business uses its own username and password.

Password management: Individual ACL account passwords can be reset without affecting others.

Reduced misoperation risk: Read-only accounts for query scenarios lower the chance of accidental writes or deletes.

Platform-managed: Account creation, password retrieval, reset, and deletion are all handled through the Zhihui Cloud control plane.

5. Summary

Zhihui Cloud Redis ACL does more than add multi-account support; it upgrades Redis access control from instance-level shared password to account-level permission governance . Previously, a single instance was typically shared by multiple businesses via the default account and one password, coupling accounts, permissions, and business boundaries together. As the business footprint expands, this coupling inflates management overhead and risk in password rotation, permission revocation, fault isolation, and security auditing.

With ACL, the platform can gradually evolve toward:

One instance

Multiple independent accounts

Independent authentication credentials

On-demand read-write permission assignment

Business-aligned access boundaries

For developers, the integration experience stays nearly the same — just add a username when isolation is needed. For operators, accounts, passwords, and permissions become independently manageable; a password change, permission adjustment, or account decommission for one business no longer impacts others, making fault and security blast radii easier to contain.

Zhihui Cloud retains the default account for legacy compatibility while recommending that new businesses, multi-tenant instances, query/analysis workloads, and any scenario requiring independent credential rotation adopt ACL accounts first. This incremental approach achieves account governance without a forced big-bang migration.

Core principle: Account matches business identity, permissions follow least privilege, and changes are contained within a single account.

This shift means Redis security moves beyond "can this client connect?" to "who can access, what operations are allowed, and how large is the impact radius?" — a key step in Zhihui Cloud Redis evolving from basic authentication to platform-grade permission governance.