Redis Permissions
You set up redis permissions by defining user accounts with command and key rules. These rules control which commands a user can run and which keys they read. Most teams start by sharing one default admin account across every app and engineer. When permissions are that broad, one bad command can wipe or expose production data. How redis permissions work under the hood Modern Redis versions include a built-in role system for user rules. Before this feature existed, every client logged in with
Redis Access Control Lists + AI Agent Permissions: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up redis permissions by defining user accounts with command and key rules. These rules control which commands a user can run and which keys they read. Most teams start by sharing one default admin account across every app and engineer. When permissions are that broad, one bad command can wipe or expose production data.
How redis permissions work under the hood
Modern Redis versions include a built-in role system for user rules. Before this feature existed, every client logged in with one shared password. That single password gave full control over every key and every command. Today, admins can create separate named users for each service and team member.
Each user profile holds three main parts in memory. First, it stores the login state and password hashes for that user. Second, it lists the exact commands or command groups the user can run. Third, it defines the key name patterns the user can read or write.
You can group commands into broad categories like read, write, or admin tasks. For example, a reporting script only needs read commands to pull metrics. You can block dangerous admin commands that clear memory or shut down the server. You can also block slow scan commands that freeze the main thread.
Key patterns let you split one data store across multiple apps. A billing service can get rules that match only billing keys. A session service can get rules that match only user session keys. If the billing app tries to read a session key, the server blocks it.
Where you store and update user rules
Teams manage these user rules in one of two ways. You can write the rules directly in the main server settings file. Or you can store them in a separate external rule file on disk. When you update the external file, the server can reload rules without a restart.
Many teams also run commands in a live session to update users. Still, changes made in memory disappear if the server restarts before you save them. In cluster setups, you must push user rule changes to every node. If one node misses an update, apps will fail when they hit that node.
Redis Access Control Lists + AI Agent Permissions: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native rules solve and what they leave open
Native rules do a good job of separating apps from each other. They stop a read-only service from deleting keys by mistake. They also stop one microservice from reading keys owned by another team. This setup gives you a strong baseline for service-to-service traffic.
Still, static user rules create friction when human engineers need to fix live issues. Engineers often share a single admin user or read-only user to check production keys. Because they share one login, the server logs cannot show which person ran a command. You only see the shared role name in the logs.
Native permissions also decide who logs in, not what data comes back in flight. Once a user has read permissions on a key pattern, they get the whole value. Key values often store JSON payloads with emails, phone numbers, or card numbers. Native Redis rules cannot rewrite matched fields in results before they reach the screen.
Finally, standing permissions stay active all day and night. If an engineer needs write permissions for ten minutes, the rule often keeps the session active forever. Teams have to build custom scripts to grant and revoke user rules on a schedule. Without automated cleanup, old accounts pile up across every node in the cluster.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What happens to the default user when I add new users?
The default user stays active with full permissions unless you change or disable it. Best practice is to lock down the default user once named accounts are ready. That forces every client and person to log in with a specific user profile.
Can I restrict a user to read-only commands on specific keys?
Yes, modern Redis rules let you pair command categories with specific key patterns. You can grant a user the read command group for only one key prefix. You can even set separate key patterns for read tasks versus write tasks.
How do Redis permissions work with pub/sub channels?
User profiles also include channel patterns alongside key and command rules. By default, new users might have broad or restricted channel rules depending on your version. You can limit which channels a user can publish to or subscribe to using patterns.