The problem/use-case that the feature addresses

We've had several folks at AWS request improvements to auditing for compliance and/or security purposes. They are mainly interested in the following cases in the given order: 1. Which user accessed the database at which time with which permissions. 2. What changes occurred to data, and from which user and IP was the data modified. 3. Who accessed what data at what point in time. 4. Full auditing of all commands and when they occurred.

Depending on which user we talked to, different folks had different opinions on the requirements.

Description of the feature

Native Redis support for recording the mentioned data, with configuration options to determine what level is being audited. I think 1) is not that hard to sell as an idea. The remaining items are basically just high volume writes to disk in some format.

I also kind of want to revisit the conversation of implementing these types of features as modules, specifically one that is included by default in our docker container and rpm (and maybe stack?). That way they are more or less included by default, but we could potentially better scale the team by having it in a separate github package. (Could also be a "first" party module").

Alternatives you've considered

  1. I believe this could be technically implemented as a module. Filtering allows us to see each command. Something better might be the interceptors that were discussed in https://github.com/redis/redis/issues/10819.
  2. One user asked about instrumenting everything with a FUNCTION. They wanted to execute a function like FCALL EXEC 0 SET FOO BAR, which took the arguments of the argument and passed them through. This is bad for a couple of reasons, namely it doesn't declare keys.
  3. Monitor solves some of these problems, but it also can break if the client is disconnected.

Comment From: oranagra

I agree we want to do that as a first-party module. I.e add the necessary API to let the module monitor everything, and then implement and ship such a module together with redis. I feel these modules should be part of the Redis git hub repo (as long as their code-base is small and relatively static).

Comment From: madolson

The only counter argument I have to the Redis github repo is we could potentially have different permissions on other packages. If someone is very interesting in maintaining something else, we could potentially let them work on that.

We could always look into splitting up the code later though. I like the benefit of having some more logical decoupling now.

Comment From: yyyhe

Thanks @oranagra for sharing this feature link. Just want to add a specific use case here to show its nice to have auditing support (in this case command log).

We had an issue that the "FLUSHDB" command was executed unintentionally; and this was reported as a "data loss". Without accessing client request history, it would be much efficient to debug the issue if we have the auditing feature, specifically, the high impact command auditing.