Redis 6 makes client identity and transport explicit

A shared password cannot express that one application should read a particular family of keys while another performs administrative work. Redis 6.0 adds named users with command and key permissions, alongside native TLS support. Those changes let a deployment describe more of its access policy in the database itself. They also require separating application identity from the identity established by a transport certificate.

The release notes date general availability to April 30, 2020. The tagged release notes describe the final changes from the previous candidate, including ACL-style authentication for migration and the ability to disconnect clients by username. That final candidate-to-release list is only part of the major-version change. The shipped configuration explains the larger access model.

I have used Redis since its release, and I like the directness of its commands. Named permissions make that directness more useful when several applications share the service. The permissions can describe the commands and key names an application actually needs, while keeping administrative authority a separate decision.

A user has commands and key patterns

The Redis 6.0 configuration defines users through ACL rules. Rules can enable or disable a user, allow individual commands and add permitted key patterns. Command categories provide a broader grouping, and individual commands can be removed after a category is granted.

For example, a user intended to read session strings can begin from reset permissions and receive only a small command set. The following is an illustrative configuration entry, with a placeholder password that must be replaced.

user session-reader reset on >replace-with-a-random-secret ~session:* +get +mget +ping

The reset rule clears password state, key permissions and command permissions and disables the user before subsequent rules apply. Subsequent rules enable this identity, set a password and allow the named commands. The key pattern restricts the keys mentioned by key-bearing commands. It does not give permission to every command that happens to accept a matching key.

A rule sequence is processed left to right. The configuration illustrates that granting all commands and then removing one differs from removing one before granting all commands. This is important when composing a policy through fragments. The final permissions depend on ordering, so the fragments cannot be treated as an unordered set of declarations.

The broad all-commands category also includes commands that modules may load later. Granting that category therefore makes a statement about future module commands as well as the commands currently present. An explicit command list has a different scope. The choice belongs in the policy itself because the two forms express different authority.

Disabling a user does not terminate its sessions

The off rule prevents new authentication as that user. The configuration explicitly says already authenticated connections continue to work. This gives user state and connection state separate lifetimes. A disabled identity is not, by that action alone, evidence that all its sessions have disappeared.

The release adds CLIENT KILL USER to target connections associated with a username. That makes the distinction actionable. Preventing new authentication and disconnecting existing clients are separate operations, and the final release supplies a command for the latter.

Password state also has explicit rules. A user can have several accepted passwords, with additions and removals represented separately. The passwordless flag has its own meaning, and resetting passwords clears that condition. These distinctions matter when changing credentials because removing one password is not the same operation as disabling the user.

The default user preserves compatibility with earlier clients. New connections begin with that identity, and a passwordless default user authenticates them immediately. The older requirepass setting now assigns a password to the default user. Clients using the older single-password authentication form can continue to use it, while the explicit form includes the default username.

This compatibility mechanism gives an existing client a route into the new model. It does not automatically divide applications into separate identities. A deployment that retains one shared default credential retains the corresponding shared access relationship until its policy and clients are changed.

Policy storage has a startup rule

ACL users can live in the main configuration or in a separate ACL file. The shipped comments say these approaches cannot be mixed. Configuring inline users while enabling the external file makes the server refuse to start.

That rule is relevant to deployment templates. A main configuration that inherits example user entries and also enables a separately managed ACL file is not simply providing two sources that the server merges. Its startup behaviour rejects the combination. The representation chosen for policy storage therefore needs to be consistent across the generated configuration.

Redis also provides an ACL log for failed commands and authentication events associated with ACLs. Its configured maximum length is 128. That makes it useful for diagnosing a denied request, but its bounded history should not be described as a permanent record of all access decisions.

TLS authenticates the connection separately

Native TLS support is disabled by default. The configuration can disable the ordinary TCP listener with port 0 and enable a TLS listener through tls-port. The server uses a certificate and private key in PEM format, with explicitly configured certificate authorities for authenticating peers.

The configuration does not silently use the system certificate-authority store. At least a CA bundle or CA directory must be supplied. That requirement makes the trust material part of the Redis configuration rather than an implicit dependency on the operating system's current certificate set.

Clients on a TLS port must present valid client certificates by default, including replicas connecting as clients. An explicit option can disable that requirement. A transport that encrypts traffic and a transport that requires client certificates are therefore separately configurable aspects of the connection.

A client certificate does not, from these settings alone, select an ACL username. The configuration describes the transport authentication requirement and the ACL authentication rules separately. Both need a defined role in the deployment. Conflating them would obscure which credentials establish the application permissions used for commands.

Replication links and the cluster bus have their own TLS switches. Turning on a client listener does not establish that every Redis connection uses TLS. The server-to-server links need their corresponding settings. This is a concrete reason to describe the topology when explaining what a TLS configuration protects.

I/O threads have a narrower job than command execution

Redis 6 also provides optional I/O threads. The shipped configuration describes their default task as transferring client output buffers to sockets through write calls. An additional option enables threaded reads and protocol parsing. These are network-processing changes, so their presence should not be described as every command executing concurrently.

Setting the thread count to one uses the main thread. The configuration also says the setting cannot be changed at runtime through CONFIG SET. Enabling the feature is therefore a startup configuration choice, rather than a live control that an operator can assume is available on any running instance.

There is a direct interaction with the other major addition. The release configuration says I/O threading does not currently work when SSL is enabled. Native TLS and I/O threads are not independent switches whose advertised effects can simply be added together for this release. A description of the network path needs to account for their compatibility.

That limitation is useful context for the release's broader direction. Redis is making network work and access policy more explicit while keeping separate controls for each. A configuration can describe named application permissions and encrypted connections without implying a particular throughput result.

The final release includes client-level controls

The tagged notes add migration support for ACL-style authentication through MIGRATE AUTH2. They also add a client-tracking option to suppress invalidations caused by the client's own changes. Both changes give a client a way to participate in the new identity or notification model explicitly.

These additions illustrate why a major-version upgrade has several adoption stages. Running the new executable makes the commands available. Using a named identity or a client-tracking option requires the corresponding client behaviour and configuration. The release does not infer an application's intended access boundary merely from its existing connection.

I value the ACL model most where it can state a real application's permissions in a reviewable form. Redis 6 provides command rules, key patterns and named sessions, while TLS describes a separate transport trust relationship. Its configuration also states where the new network features interact, including the current incompatibility between SSL and I/O threading.