ACL rules and categories in Redis - Deep Dive

Overview - ACL rules and categories

What is it?

ACL rules and categories in Redis are a way to control who can do what with the database. ACL stands for Access Control List, which means a list of permissions assigned to users. These rules define which commands or keys a user can access or modify. This helps keep the database safe and organized by limiting access.

Why it matters

Without ACL rules, anyone who connects to Redis could run any command, which can cause data loss, security breaches, or accidental mistakes. ACL rules protect sensitive data and operations by giving users only the permissions they need. This is especially important in shared environments or production systems where many people or applications use the same Redis server.

Where it fits

Before learning ACL rules, you should understand basic Redis commands and how users connect to Redis. After mastering ACL rules, you can learn about Redis security best practices and advanced user management.

Mental Model

Core Idea

ACL rules in Redis are like a security guard who checks a list of allowed actions for each user before letting them do anything.

Think of it like...

Imagine a library where each visitor has a card that says which sections they can enter and which books they can borrow. The ACL rules are like those cards, controlling access to different parts of the library.

┌─────────────┐       ┌───────────────┐       ┌───────────────┐
│   User A    │──────▶│  ACL Rules    │──────▶│ Allowed Cmds  │
│ (username)  │       │ (permissions) │       │ & Key Access  │
└─────────────┘       └───────────────┘       └───────────────┘

Each user has a set of ACL rules that define which commands and keys they can use.

Build-Up - 7 Steps

1

Foundation

What is Redis ACL and Users

Concept: Introduction to Redis ACL system and user management.

Redis ACL allows you to create users with specific permissions. Each user can have a password and a set of rules that control what commands and keys they can access. By default, Redis has a default user with no password and full access, but you can create new users with limited rights.

Result

You understand that Redis ACL is about creating users and controlling their access.

Knowing that Redis ACL is user-based helps you see how permissions are tied to identities, not just commands.

2

Foundation

Basic ACL Rule Syntax

Concept: How to write simple ACL rules for commands and keys.

ACL rules use prefixes like + or - to allow or deny commands, and patterns to allow or deny keys. For example, '+GET' allows the GET command, '-DEL' denies the DEL command, and '~cache:*' allows access to keys starting with 'cache:'.

Result

You can write simple rules to allow or block commands and keys.

Understanding the syntax lets you control access precisely, avoiding accidental permission leaks.

3

Intermediate

Command Categories in ACL

🤔Before reading on: do you think Redis ACL rules list every command individually or group them?

Concept: Redis groups commands into categories to simplify ACL management.

Instead of listing every command, Redis ACL uses categories like @read, @write, @admin, etc. You can allow or deny entire categories with rules like '+@read' to allow all read commands or '-@dangerous' to block risky commands.

Result

You can manage permissions more easily by using command categories.

Knowing categories reduces complexity and helps avoid missing commands when setting permissions.

4

Intermediate

Key Patterns and Access Control

🤔Before reading on: do you think ACL key patterns allow partial or exact key matching?

Concept: ACL key rules use glob-style patterns to control access to keys.

You can specify key access with patterns like '~user:*' to allow keys starting with 'user:'. This controls which keys a user can read or write. Denying keys outside the pattern prevents unauthorized data access.

Result

You can restrict users to only certain parts of the database by key patterns.

Understanding key patterns helps you protect sensitive data and organize permissions logically.

5

Intermediate

Combining Command and Key Rules

Concept: How command and key rules work together to define full access control.

A user's permissions are the combination of allowed commands and allowed keys. Even if a command is allowed, if the key is not allowed by pattern, the command will fail. This two-level check ensures fine-grained control.

Result

You can create precise permission sets that limit both what commands and which keys users can access.

Knowing the combined effect prevents security holes where users might run allowed commands on forbidden keys.

6

Advanced

ACL Categories and Dangerous Commands

🤔Before reading on: do you think all commands in Redis are safe to allow by default?

Concept: Some command categories are considered dangerous and should be restricted carefully.

Categories like @dangerous include commands that can delete data or change server state. By default, these are denied unless explicitly allowed. Understanding these categories helps you avoid accidental data loss or server misuse.

Result

You can protect your Redis server by carefully managing dangerous command categories.

Recognizing dangerous commands helps you build safer ACL policies and avoid costly mistakes.

7

Expert

ACL Rule Evaluation and Performance

🤔Before reading on: do you think Redis checks ACL rules once per connection or per command execution?

Concept: Redis evaluates ACL rules on every command execution for each user, affecting performance and security.

When a user sends a command, Redis checks if the command and key match the user's ACL rules. This check happens every time, ensuring up-to-date enforcement. Complex patterns or many rules can impact performance, so rules should be as simple and efficient as possible.

Result

You understand the tradeoff between ACL complexity and Redis performance.

Knowing how ACL checks work internally helps you design efficient rules that keep Redis fast and secure.

Under the Hood

Redis stores ACL users and their rules in memory. When a command arrives, Redis identifies the user by their connection, then checks the command against allowed commands and the key against allowed patterns. This check uses efficient data structures like tries and hash tables to quickly match commands and keys. If the command or key is not allowed, Redis rejects the command immediately.

Why designed this way?

This design balances security and speed. Checking permissions on every command prevents unauthorized access even if rules change dynamically. Using categories and patterns reduces the number of rules needed, making the system scalable. Alternatives like static permissions or external authorization would slow down Redis or complicate management.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Client sends  │──────▶│ Identify User │──────▶│ Check ACL     │
│ command/key   │       │ by connection │       │ rules: cmds & │
└───────────────┘       └───────────────┘       │ keys patterns │
                                                └───────────────┘
                                                      │
                                                      ▼
                                           ┌─────────────────────┐
                                           │ Allow or Deny cmd   │
                                           └─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does allowing a command automatically allow access to all keys for that command? Commit yes or no.

Common Belief: If a command is allowed, the user can run it on any key.

Reality: Even if a command is allowed, the user can only run it on keys matching their allowed key patterns.

Why it matters: Assuming command allowance means full key access can lead to accidental data exposure.

Quick: Do you think denying a command category overrides individual command allowances? Commit yes or no.

Common Belief: Denying a category blocks all commands in it, even if individually allowed.

Reality: Deny rules take precedence over allow rules, so denying a category blocks all commands in it regardless of individual allows.

Why it matters: Misunderstanding rule precedence can cause unexpected permission denials or security holes.

Quick: Can Redis ACL rules be bypassed by connecting without authentication? Commit yes or no.

Common Belief: If a user connects without authentication, ACL rules do not apply.

Reality: Redis requires authentication for users with ACL rules; unauthenticated connections have no permissions and cannot run commands.

Why it matters: Thinking unauthenticated users have access can cause false security assumptions.

Quick: Do you think all Redis commands are included in ACL categories? Commit yes or no.

Common Belief: All commands are grouped into categories for ACL.

Reality: Some new or rarely used commands may not be categorized and require individual rules.

Why it matters: Relying only on categories can miss permissions for uncategorized commands, causing unexpected denials.

Expert Zone

1

ACL rules are evaluated per command, so complex key patterns can slow down command processing subtly under heavy load.

2

The default user in Redis has no password and full access unless explicitly changed, which is a common security risk if left unchanged.

3

Redis ACL supports command renaming to disable commands by renaming them to empty strings, adding another layer of control beyond ACL rules.

When NOT to use

ACL rules are not suitable for very dynamic or context-dependent permissions, such as per-session or per-IP restrictions. In such cases, use external proxy layers or application-level access control. Also, ACL is not a replacement for network-level security or encryption.

Production Patterns

In production, teams often create multiple users with roles like 'read-only', 'write-only', and 'admin', using command categories and key patterns to enforce least privilege. They also regularly audit ACL rules and disable the default user. Some use ACL in combination with Redis Sentinel or Cluster for secure multi-node setups.

Connections

Role-Based Access Control (RBAC)

Redis ACL rules implement a form of RBAC by assigning permissions to users based on roles defined by command categories and key patterns.

Understanding RBAC concepts helps grasp how Redis ACL organizes permissions efficiently and securely.

Firewall Rules

Both Redis ACL and firewall rules filter allowed actions based on defined policies, controlling access to resources.

Knowing firewall principles clarifies why ACL rules must be precise and carefully ordered to avoid security gaps.

Library Borrowing Systems

Like ACL controls user access to commands and keys, library systems control which books or sections a visitor can access based on their membership type.

This cross-domain connection shows how access control is a universal problem solved by similar patterns.

Common Pitfalls

#1 Allowing all commands but forgetting to restrict keys.

Wrong approach:

ACL SETUSER alice on >password +@all

Correct approach:

ACL SETUSER alice on >password +@all ~user:alice:*

Root cause:

Misunderstanding that command allowance alone does not restrict key access, leading to over-permission.

#2 Denying a command category after allowing individual commands in it.

Wrong approach:

ACL SETUSER bob on >password +GET +SET -@write

Correct approach:

ACL SETUSER bob on >password +GET +SET

Root cause:

Not realizing deny rules override allow rules, causing unexpected denials.

#3 Leaving the default user enabled with no password.

Wrong approach:

No changes to default user after Redis installation.

Correct approach:

ACL SETUSER default off

Root cause:

Assuming default user is secure by default, exposing Redis to unauthorized access.

Key Takeaways

Redis ACL rules control user permissions by combining allowed commands and key patterns.

Command categories simplify permission management but require careful use to avoid blocking needed commands.

ACL checks happen on every command, so rules should be efficient to maintain performance.

Misunderstanding rule precedence or key pattern matching can cause security risks or access problems.

In production, always disable the default user and use least privilege principles with ACL.