Autenticación y autorización

Redis is super fast and often holds sensitive data. Without proper security, your data could be exposed or modified by unauthorized users. Just like your house, your database needs locks!

This lesson will teach you how to set up basic authentication with passwords and advanced authorization using Access Control Lists (ACLs) to protect your Redis instances.

The simplest way to secure Redis is using the requirepass directive in your redis.conf file. This sets a global password that clients must provide to execute *any* command.

It's like a single master key for everyone.

Once requirepass is set, clients connecting to Redis must authenticate using the AUTH command. If the password is wrong, most commands will fail.

Here's how you'd connect via redis-cli and authenticate:

While easy to set up, requirepass has a major limitation: it's a single password for everyone and everything. All authenticated clients have full access to all commands and data.

• No specific user accounts.
• No fine-grained permissions (e.g., read-only for some).
• Hard to manage in complex applications.

This is where Redis Access Control Lists (ACLs) come in handy!

Redis ACLs (Access Control Lists) allow you to define multiple users, each with their own password and a specific set of permissions. This provides much finer control over who can do what.

You can control:

• Which commands a user can execute.
• Which keys a user can access.

It's like having different keys for different rooms in your house.

You manage ACLs directly through Redis commands, either in redis-cli or programmatically. The ACL SETUSER command is central to defining users and their properties.

Let's create a new user named app_user with a password. The > before the password indicates it's a password.

With ACLs, you can specify exactly which commands a user can run. Permissions are often given in categories (like @all, @read, @write) or specific command names.

• +@read: Grants all read-only commands.
• -@admin: Revokes all administrative commands.
• +SET: Grants only the SET command.

Here's an example for our app_user, granting read/write but denying admin commands:

Beyond commands, ACLs let you restrict access to specific keys or key patterns. This is incredibly powerful for multi-tenant applications or microservices.

• ~mykey: Access only to the key 'mykey'.
• ~data:*: Access to any key starting with 'data:'.
• ~*: Access to all keys (use with caution!).

Let's refine app_user to only access keys starting with user_data::

To maximize security with ACLs, follow these best practices:

• Principle of Least Privilege: Grant only the necessary permissions. Avoid +@all if not strictly needed.
• Strong Passwords: Use unique, complex passwords for each user. Rotate them regularly.
• Disable Default User: If not used, disable the default user or give it a strong password and minimal permissions.
• Audit Regularly: Periodically review your ACL configurations using ACL LIST.

Consider a Redis instance where you want a user named report_viewer to:

• Only read data.
• Only access keys starting with reports:.
• Have the password ViewerPass!.

Which of the following commands would correctly configure this user?

Great job! You've learned how to secure your Redis instances:

• requirepass: Provides simple, global password protection.
• AUTH: The command used by clients to authenticate.
• ACLs: Offer advanced, granular control over users, commands, and specific keys.
• ACL SETUSER: The primary command to create/modify users and set their permissions.
• Best Practices: Always follow the principle of least privilege, use strong passwords, and audit your configurations.

Protecting your data is crucial, and Redis provides powerful tools to do just that!