Security

By default Redis binds every network interface. If it is started that way with no password configured, it enters protected mode: it accepts connections only from the loopback interface and replies to any other client with an error explaining how to fix the configuration, rather than silently exposing the dataset. This is a safety net, not a substitute for firewalling — an administrator can still disable protected mode or bind all interfaces deliberately, and a single unauthenticated FLUSHALL from an exposed instance is enough to delete the whole dataset. The durable fix is to bind only the interfaces Redis actually needs to listen on:

See Redis security.

Redis has two authentication layers. The legacy one, requirepass, sets a single shared password for the default user and predates fine-grained permissions — every client that knows it can run every command against every key. The recommended layer, introduced in Redis 6, is the ACL system: named users, each with its own passwords, key patterns, channel patterns, and command permissions, configured with ACL SETUSER. requirepass still works and is implemented as setting a password on the default user, so the two are not mutually exclusive — a deployment typically disables or restricts default and creates a named ACL user per application instead.

ACL SETUSER username [on\|off] [>password\|nopass] [~keypattern …​] [&channelpattern …​] [+command\| +@category\|-command\|-@category …​] [reset] builds up a user’s permissions rule by rule, left to right; repeated calls add to the existing user rather than replacing it (reset clears it first). A bookshop-app user restricted to the Bookshop keyspace, needing only search and general read/write access, and explicitly denied the dangerous administrative surface, looks like this:

~bookshop:* is a glob key pattern — the user can only reference keys under that prefix as command arguments, though a command with no key arguments (FLUSHALL, FLUSHDB) is governed by command rules alone, not key patterns, so -@dangerous above is what actually keeps bookshop-app from wiping the database. &bookshop-events:* is the matching channel pattern for Pub/Sub. @read`/`@write grant the ordinary data commands, and +@search specifically adds the FT.*/query-engine command family — a user also needs a key pattern covering an index’s declared prefixes to create, alter, or query it, since @search commands are additionally checked against the index’s own key prefixes. The equivalent category for JSON document commands is @json. ACL CAT lists every category, and ACL CAT <category> lists the commands inside one.

ACL LOG [count\|RESET] returns recent permission failures (wrong password, denied command, denied key) with a timestamp, the offending username, and the reason — the first place to look when a client reports NOPERM or WRONGPASS unexpectedly:

Users defined with ACL SETUSER live only in memory unless saved. For more than a handful of users, an external ACL file (aclfile /etc/redis/users.acl, one user …​ line per user in the same rule syntax) is easier to version and review than embedding users in redis.conf; ACL LOAD reloads it after a manual edit, and ACL SAVE writes the current in-memory users back out to it.

See ACL and ACL SETUSER.

Redis supports TLS on every communication channel — client connections, replication links, and the cluster bus — as an optional feature that must be compiled in and then explicitly enabled. tls-port opens a TLS listener in addition to (or, with port 0, instead of) the plain-text port, and a certificate, private key, and trusted CA bundle must be configured for it to start:

By default Redis requires mutual TLS: a connecting client must present a certificate signed by a trusted CA, not only verify the server’s — tls-auth-clients no relaxes this to server-only authentication when a deployment cannot issue per-client certificates. redis-cli authenticates the same way any client does, supplying its own certificate and key alongside --tls:

Redis 8.6 added certificate-based user authentication: with tls-auth-clients-user set to a certificate field (for example CN), the value of that field on the client’s certificate is used directly as the ACL username, so a client authenticated at the TLS layer needs no separate AUTH call — failed attempts surface in the acl_access_denied_tls_cert metric. Redis 8.10 added TLS peer certificate-based server-to-server authentication: cluster bus and replication links can now verify the peer’s certificate against the CA the same way a client connection does, closing the gap where tls-cluster yes encrypted node-to-node traffic without also authenticating which node was on the other end.

See TLS, Redis Open Source 8.6 release notes, and Redis Open Source 8.10 release notes.

rename-command in redis.conf renames a command to an unguessable string, or to an empty string to disable it outright — historically used to keep operators-only commands out of reach of application clients on a shared instance:

This mechanism is deprecated in favor of ACL rules, since rename-command is a single global setting — it hides a command from every user equally, whereas -@dangerous (or -flushall, -keys, -config) on a specific ACL user like bookshop-app restricts only that user and can differ per user. KEYS in particular scans the whole keyspace and blocks the server while it runs, so it is worth denying to every application user regardless of method; SCAN is the incremental, non-blocking alternative for the same purpose.

See Redis security.

ACLs and TLS assume the network itself is not the last line of defense. In practice that means: put Redis on a private subnet with no public IP, allow inbound traffic on port/tls-port only from the application tier’s security group or firewall rule, and never expose the port directly to the internet even with a password set, since AUTH and unencrypted requirepass traffic can still be observed by anyone already on the network path. Container images should use a current base such as redis:8, not an older redis/redis-stack image, since the module surface (search, JSON, probabilistic, time series) that used to require a separate redis-stack image ships in Redis 8 itself. Redis Cloud and Redis Software deployments add further isolation options (VPC peering, private endpoints) on top of the same bind/firewall/TLS model.

See Redis security.