Redis Security

作者 redisa84871d065f3MIT收錄於 2026年10月8日更新於 2026年10月8日

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.

僅含說明Security
AI 產生的概覽

指導透過身分驗證、ACL 最小權限、TLS 與網路限制來強化 Redis 部署。

功能
此技能為 Redis 正式環境強化提供指引,涵蓋使用 requirepass 與 ACL 使用者進行身分驗證、TLS 設定、以 ACL 為基礎的最小權限存取控制、透過 bind 與 protected-mode 限制網路暴露、防火牆規則,以及停用危險命令。它會產出 redis.conf、ACL SETUSER、iptables 與用戶端連線設定的設定片段與命令範例。它也指向三份參考文件,分別關於身分驗證、ACL 與網路暴露。
適用情境
適用於將 Redis 執行個體部署或審查於正式環境、為應用程式定義 ACL 使用者、設定 TLS 連線、在防火牆後鎖定 Redis 執行個體,或依據安全發現稽核 Redis 部署的情境。
執行需求
沒有指令碼,僅為指引說明。套用這些指引需要既有的 Redis 部署;範例另需 Redis 用戶端函式庫(例如 redis-py),以及存取 redis.conf、ACL 命令與防火牆工具的能力。

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.confrequirepass your-strong-passwordtls-port 6380tls-cert-file /path/to/redis.crttls-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 [blocked].

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 readerACL SETUSER app_readonly on >password ~cache:* +get +mget +scan
# Writer that can't run dangerous opsACL SETUSER app_writer   on >password ~*        +@all -@dangerous
# Admin (use sparingly, never for application traffic)ACL SETUSER admin        on >strong-password ~* +@all

Useful command categories:

CategoryWhat it covers
@readRead commands (GET, MGET, HGET, ...)
@writeWrite commands (SET, DEL, XADD, ...)
@dangerousFLUSHALL, DEBUG, KEYS, etc.
@adminAdministrative 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 [blocked].

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 onbind 127.0.0.1 192.168.1.100protected-mode yes
bash
# Firewall — allow only application subnetsiptables -A INPUT -p tcp --dport 6379 -s 192.168.1.0/24 -j ACCEPTiptables -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 [blocked].

References

來源與署名

來源:redis/agent-skills位於plugins/redis-development/skills/redis-security提交a84871d

授權條款: MIT

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架