redis-security

Name: redis-security
Author: redis

867installs22forks

How to install redis-security?

redis/agent-skills/redis-security

$npx -y skills add redis/agent-skills --skill redis-security

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Redis Security
2
3	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.
4
5	## When to apply
6
7	- Deploying or reviewing a Redis instance destined for production.
8	- Setting up application credentials beyond a shared password.
9	- Auditing a Redis deployment against a security checklist.
10	- Receiving "Redis exposed to the internet" findings from a scanner.
11
12	## 1. Always authenticate (and use TLS)
13
14	Never run a production Redis without a password. Pair authentication with TLS so credentials and data aren't sent in clear text.
15
16	```
17	# redis.conf
18	requirepass your-strong-password
19	tls-port 6380
20	tls-cert-file /path/to/redis.crt
21	tls-key-file /path/to/redis.key
22	```
23
24	```python
25	r = redis.Redis(
26	host="localhost",
27	port=6380,
28	password="your-strong-password",
29	ssl=True,
30	ssl_cert_reqs="required",
31	)
32	```
33
34	If you can use ACL users (next section) instead of the single `requirepass`, do — `requirepass` is effectively the legacy "default user" shortcut.
35
36	See [references/auth.md](references/auth.md).
37
38	## 2. ACLs for least-privilege access
39
40	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.
41
42	```
43	# Cache-only reader
44	ACL SETUSER app_readonly on >password ~cache:* +get +mget +scan
45
46	# Writer that can't run dangerous ops
47	ACL SETUSER app_writer on >password ~* +@all -@dangerous
48
49	# Admin (use sparingly, never for application traffic)
50	ACL SETUSER admin on >strong-password ~* +@all
51	```
52
53	Useful command categories:
54
55	\| Category \| What it covers \|
56	\|---\|---\|
57	\| `@read` \| Read commands (`GET`, `MGET`, `HGET`, ...) \|
58	\| `@write` \| Write commands (`SET`, `DEL`, `XADD`, ...) \|
59	\| `@dangerous` \| `FLUSHALL`, `DEBUG`, `KEYS`, etc. \|
60	\| `@admin` \| Administrative commands \|
61
62	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.
63
64	See [references/acls.md](references/acls.md).
65
66	## 3. Restrict network access
67
68	The most common Redis breach is a public-internet Redis with no auth. Avoid that with three layers:
69
70	```
71	# redis.conf — bind to specific interfaces, keep protected-mode on
72	bind 127.0.0.1 192.168.1.100
73	protected-mode yes
74	```
75
76	```bash
77	# Firewall — allow only application subnets
78	iptables -A INPUT -p tcp --dport 6379 -s 192.168.1.0/24 -j ACCEPT
79	iptables -A INPUT -p tcp --dport 6379 -j DROP
80	```
81
82	Anti-pattern: `bind 0.0.0.0` + `protected-mode no` — exposes Redis to the whole network without protection.
83
84	Optional but recommended: rename or disable destructive commands so a compromised client can't trash the DB:
85
86	```
87	rename-command FLUSHALL ""
88	rename-command DEBUG ""
89	rename-command CONFIG ""
90	```
91
92	See [references/network.md](references/network.md).
93
94	## References
95
96	- [Redis: Security](https://redis.io/docs/latest/operate/oss_and_stack/management/security/)
97	- [Redis: ACL](https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl/)

People who liked this also viewed

6 picks

Type

redis-security

867installs22forks

View on GitHub

How to install redis-security?

redis/agent-skills/redis-security

$npx -y skills add redis/agent-skills --skill redis-security

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Redis Security
2
3	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.
4
5	## When to apply
6
7	- Deploying or reviewing a Redis instance destined for production.
8	- Setting up application credentials beyond a shared password.
9	- Auditing a Redis deployment against a security checklist.
10	- Receiving "Redis exposed to the internet" findings from a scanner.
11
12	## 1. Always authenticate (and use TLS)
13
14	Never run a production Redis without a password. Pair authentication with TLS so credentials and data aren't sent in clear text.
15
16	```
17	# redis.conf
18	requirepass your-strong-password
19	tls-port 6380
20	tls-cert-file /path/to/redis.crt
21	tls-key-file /path/to/redis.key
22	```
23
24	```python
25	r = redis.Redis(
26	host="localhost",
27	port=6380,
28	password="your-strong-password",
29	ssl=True,
30	ssl_cert_reqs="required",
31	)
32	```
33
34	If you can use ACL users (next section) instead of the single `requirepass`, do — `requirepass` is effectively the legacy "default user" shortcut.
35
36	See [references/auth.md](references/auth.md).
37
38	## 2. ACLs for least-privilege access
39
40	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.
41
42	```
43	# Cache-only reader
44	ACL SETUSER app_readonly on >password ~cache:* +get +mget +scan
45
46	# Writer that can't run dangerous ops
47	ACL SETUSER app_writer on >password ~* +@all -@dangerous
48
49	# Admin (use sparingly, never for application traffic)
50	ACL SETUSER admin on >strong-password ~* +@all
51	```
52
53	Useful command categories:
54
55	\| Category \| What it covers \|
56	\|---\|---\|
57	\| `@read` \| Read commands (`GET`, `MGET`, `HGET`, ...) \|
58	\| `@write` \| Write commands (`SET`, `DEL`, `XADD`, ...) \|
59	\| `@dangerous` \| `FLUSHALL`, `DEBUG`, `KEYS`, etc. \|
60	\| `@admin` \| Administrative commands \|
61
62	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.
63
64	See [references/acls.md](references/acls.md).
65
66	## 3. Restrict network access
67
68	The most common Redis breach is a public-internet Redis with no auth. Avoid that with three layers:
69
70	```
71	# redis.conf — bind to specific interfaces, keep protected-mode on
72	bind 127.0.0.1 192.168.1.100
73	protected-mode yes
74	```
75
76	```bash
77	# Firewall — allow only application subnets
78	iptables -A INPUT -p tcp --dport 6379 -s 192.168.1.0/24 -j ACCEPT
79	iptables -A INPUT -p tcp --dport 6379 -j DROP
80	```
81
82	Anti-pattern: `bind 0.0.0.0` + `protected-mode no` — exposes Redis to the whole network without protection.
83
84	Optional but recommended: rename or disable destructive commands so a compromised client can't trash the DB:
85
86	```
87	rename-command FLUSHALL ""
88	rename-command DEBUG ""
89	rename-command CONFIG ""
90	```
91
92	See [references/network.md](references/network.md).
93
94	## References
95
96	- [Redis: Security](https://redis.io/docs/latest/operate/oss_and_stack/management/security/)
97	- [Redis: ACL](https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl/)

People who liked this also viewed

6 picks

Type