Claude
Cursor
Skill
redis-security
Redis security guidance covering authentication (requirepass and ACL users), TLS, ACL-based least-privilege access control, restricting network exposure via bind and protected-mode, firewall rules, and disabling dangerous commands. Use when deploying Redis to production, defining
Virus-scanned
Reviewed automatically before listing.
Download
redis-agent-skills-plugins_redis-development_skills_redis-security-172fb9e.zip · 3 KB
Install
skills CLI
npx skills add https://github.com/redis/agent-skills/tree/main/plugins/redis-development/skills/redis-security
Claude Code
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install redis-agent-skills@llmmart
Git
git clone https://github.com/redis/agent-skills.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole redis/agent-skills collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Redis Security
Production hardening for Redis: authentication, ACL-based access control, and network exposure. Cover all three together — any one of them on its own leaves an exploitable gap.
When to apply
- Deploying or reviewing a Redis instance destined for production.
- Setting up application credentials beyond a shared password.
- Auditing a Redis deployment against a security checklist.
- Receiving "Redis exposed to the internet" findings from a scanner.
1. Always authenticate (and use TLS)
Never run a production Redis without a password. Pair authentication with TLS so credentials and data aren't sent in clear text.
# redis.conf
requirepass your-strong-password
tls-port 6380
tls-cert-file /path/to/redis.crt
tls-key-file /path/to/redis.key
r = redis.Redis(
host="localhost",
port=6380,
password="your-strong-password",
ssl=True,
ssl_cert_reqs="required",
)
If you can use ACL users (next section) instead of the single requirepass, do — requirepass is effectively the legacy "default user" shortcut.
See references/auth.md.
2. ACLs for least-privilege access
The default user with a shared password is fine for development. For production, give each application a dedicated ACL user with only the commands and key patterns it actually needs.
# Cache-only reader
ACL SETUSER app_readonly on >password ~cache:* +get +mget +scan
# Writer that can't run dangerous ops
ACL SETUSER app_writer on >password ~* +@all -@dangerous
# Admin (use sparingly, never for application traffic)
ACL SETUSER admin on >strong-password ~* +@all
Useful command categories:
| Category | What it covers |
|---|---|
@read |
Read commands (GET, MGET, HGET, ...) |
@write |
Write commands (SET, DEL, XADD, ...) |
@dangerous |
FLUSHALL, DEBUG, KEYS, etc. |
@admin |
Administrative commands |
If app credentials leak, a tight ACL bounds the blast radius — the attacker can't FLUSHALL your DB just because they grabbed a cache reader's password.
See references/acls.md.
3. Restrict network access
The most common Redis breach is a public-internet Redis with no auth. Avoid that with three layers:
# redis.conf — bind to specific interfaces, keep protected-mode on
bind 127.0.0.1 192.168.1.100
protected-mode yes
# Firewall — allow only application subnets
iptables -A INPUT -p tcp --dport 6379 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP
Anti-pattern: bind 0.0.0.0 + protected-mode no — exposes Redis to the whole network without protection.
Optional but recommended: rename or disable destructive commands so a compromised client can't trash the DB:
rename-command FLUSHALL ""
rename-command DEBUG ""
rename-command CONFIG ""
References
Files (agent-skills)
-
references
-
acls.md 862 B
# Use ACLs for Fine-Grained Access Control Create users with only the permissions they need (principle of least privilege). **Correct:** Create specific users with limited permissions. ``` # Read-only user for cache access ACL SETUSER app_readonly on >password ~cache:* +get +mget +scan # Writer that can't run dangerous commands ACL SETUSER app_writer on >password ~* +@all -@dangerous # Admin user (use sparingly) ACL SETUSER admin on >strong-password ~* +@all ``` **Incorrect:** Using the default user for everything. ``` # Bad: Single password for all access requirepass shared-password ``` **ACL categories:** - `@read` - Read commands - `@write` - Write commands - `@dangerous` - Commands like FLUSHALL, DEBUG - `@admin` - Administrative commands Reference: [Redis ACL](https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl/) -
auth.md 1.6 KB
# Always Use Authentication in Production Never run Redis without authentication in production environments. **Correct:** Use password and TLS. **Python** (redis-py): ```python r = redis.Redis( host='localhost', port=6379, password='your-strong-password', ssl=True, ssl_cert_reqs='required' ) ``` **Java** (Jedis): ```java import redis.clients.jedis.*; import javax.net.ssl.*; import java.security.KeyStore; // Create SSL context with trust store and key store KeyStore trustStore = KeyStore.getInstance("jks"); trustStore.load(new FileInputStream("./truststore.jks"), "password".toCharArray()); TrustManagerFactory tmf = TrustManagerFactory.getInstance("X509"); tmf.init(trustStore); SSLContext sslContext = SSLContext.getInstance("TLS"); sslContext.init(null, tmf.getTrustManagers(), null); JedisClientConfig config = DefaultJedisClientConfig.builder() .ssl(true) .sslSocketFactory(sslContext.getSocketFactory()) .user("redisUser") .password("redisPassword") .build(); JedisPooled jedis = new JedisPooled(new HostAndPort("redis-host", 6379), config); ``` **Incorrect:** Connecting without authentication. **Python** (redis-py): ```python # Bad: No authentication r = redis.Redis(host='localhost', port=6379) ``` **Java** (Jedis): ```java // Bad: No authentication or TLS UnifiedJedis jedis = new UnifiedJedis("redis://localhost:6379"); ``` **Configuration:** ``` # redis.conf requirepass your-strong-password tls-port 6380 tls-cert-file /path/to/redis.crt tls-key-file /path/to/redis.key ``` Reference: [Redis Security](https://redis.io/docs/latest/operate/oss_and_stack/management/security/) -
network.md 902 B
# Secure Network Access Restrict network access to Redis to only trusted sources. **Correct:** Bind to specific interfaces. ``` # redis.conf bind 127.0.0.1 192.168.1.100 protected-mode yes ``` **Correct:** Use firewall rules. ```bash # Allow only application servers iptables -A INPUT -p tcp --dport 6379 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 6379 -j DROP ``` **Incorrect:** Exposing Redis to the internet. ``` # Bad: Binds to all interfaces bind 0.0.0.0 protected-mode no ``` **Security checklist:** - Use TLS for connections - Bind to specific interfaces, not `0.0.0.0` - Use firewall rules to restrict access - Disable dangerous commands in production ``` # Disable dangerous commands rename-command FLUSHALL "" rename-command DEBUG "" rename-command CONFIG "" ``` Reference: [Redis Security](https://redis.io/docs/latest/operate/oss_and_stack/management/security/)
-
-
SKILL.md 3.6 KB
--- name: redis-security description: Redis security guidance covering authentication (requirepass and ACL users), TLS, ACL-based least-privilege access control, restricting network exposure via bind and protected-mode, firewall rules, and disabling dangerous commands. Use when deploying Redis to production, defining ACL users for an application, configuring TLS connections, locking down a Redis instance behind a firewall, or auditing a Redis deployment for security hardening. license: MIT metadata: author: Redis, Inc. version: "0.1.0" --- # Redis Security Production hardening for Redis: authentication, ACL-based access control, and network exposure. Cover all three together — any one of them on its own leaves an exploitable gap. ## When to apply - Deploying or reviewing a Redis instance destined for production. - Setting up application credentials beyond a shared password. - Auditing a Redis deployment against a security checklist. - Receiving "Redis exposed to the internet" findings from a scanner. ## 1. Always authenticate (and use TLS) Never run a production Redis without a password. Pair authentication with TLS so credentials and data aren't sent in clear text. ``` # redis.conf requirepass your-strong-password tls-port 6380 tls-cert-file /path/to/redis.crt tls-key-file /path/to/redis.key ``` ```python r = redis.Redis( host="localhost", port=6380, password="your-strong-password", ssl=True, ssl_cert_reqs="required", ) ``` If you can use ACL users (next section) instead of the single `requirepass`, do — `requirepass` is effectively the legacy "default user" shortcut. See [references/auth.md](references/auth.md). ## 2. ACLs for least-privilege access The `default` user with a shared password is fine for development. For production, give each application a dedicated ACL user with only the commands and key patterns it actually needs. ``` # Cache-only reader ACL SETUSER app_readonly on >password ~cache:* +get +mget +scan # Writer that can't run dangerous ops ACL SETUSER app_writer on >password ~* +@all -@dangerous # Admin (use sparingly, never for application traffic) ACL SETUSER admin on >strong-password ~* +@all ``` Useful command categories: | Category | What it covers | |---|---| | `@read` | Read commands (`GET`, `MGET`, `HGET`, ...) | | `@write` | Write commands (`SET`, `DEL`, `XADD`, ...) | | `@dangerous` | `FLUSHALL`, `DEBUG`, `KEYS`, etc. | | `@admin` | Administrative commands | If app credentials leak, a tight ACL bounds the blast radius — the attacker can't `FLUSHALL` your DB just because they grabbed a cache reader's password. See [references/acls.md](references/acls.md). ## 3. Restrict network access The most common Redis breach is a public-internet Redis with no auth. Avoid that with three layers: ``` # redis.conf — bind to specific interfaces, keep protected-mode on bind 127.0.0.1 192.168.1.100 protected-mode yes ``` ```bash # Firewall — allow only application subnets iptables -A INPUT -p tcp --dport 6379 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 6379 -j DROP ``` Anti-pattern: `bind 0.0.0.0` + `protected-mode no` — exposes Redis to the whole network without protection. Optional but recommended: rename or disable destructive commands so a compromised client can't trash the DB: ``` rename-command FLUSHALL "" rename-command DEBUG "" rename-command CONFIG "" ``` See [references/network.md](references/network.md). ## References - [Redis: Security](https://redis.io/docs/latest/operate/oss_and_stack/management/security/) - [Redis: ACL](https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl/)
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.