redis-operator: Default user with too many privileges

Expected behaviour

There needs to be an admin user for the use in administrative operations. And we could make the default user -@dangerous.

Actual behaviour

The default user is has global privileges and this might cause issue if there is compromize of the application

Steps to reproduce the behaviour

FLUSHALL

This will delete everything. !!!DANGEROUS!!!

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 26 (17 by maintainers)

Most upvoted comments

For example also how a MySQL operator manages their users and databases, see here.

Wouter0100 on Oct 5, 2022

To post my 2 cents here… I haven’t read the whole thread, but wouldn’t it be possible to introduce CRD’s for this purpose? For example, a RedisFailoverUser.

Personally I’m not a fan of “authv2” and introducing a CRD aligns with decoupled user management of the RedisFailover CRD. This way you’re very easily able to deploy a new user, w/o updating the RedisFailover manifest.

Wouter0100 on Oct 4, 2022

Thanks @samof76,

I am still thinking about this feature but I have quick notes for the moment:

Redis 6 is the minimum version required for the operator. I will add a note in the README for it. It’s better to focus on the last versions than wide support on versions since we don’t have either a lot of bandwidth
Managing multiple users and securing the deployment by default is a very good feature IMHO. I would mantain certain isolation logic between redisops-admin, the user to manage the instances by the operator, and the other users.
What want you get regarding with password rotation?
- Have the operator rotating the password at intervals updating secret manifests in kubernetes along with the user password in redis?
- Have a mechanisms to allow users rotating the password updating the redis-failover manifests?
I think that we should not break the redis-failover spec so we should add a new field instead changing the spec of the current auth field

ese on Sep 8, 2022