[NEW] Trusted/un-trusted client feature

[hwware]

The problem/use-case that the feature addresses

ACL provides good access control based on the rules and also restrict the users for certain commands depending on their role, we could say offers robust access control mechanisms. In most of the cases administrators share default password within themselves and there is chance connection can be made from outside of the server's deployment network or they can create different user and connect from internet, likewise human error in ACL configurations can inadvertently open up security issues, like we can think of.

Motivation

• Addition to ACL if we have a feature like trusted client based on their network will provide additional security to the server, prevent from misuse. Having multiple layers of security is a fundamental principle in cybersecurity. While Valkey ACLs provide good control over access permissions, adding a trusted network feature offers an additional layer and strategy ensures that even if one layer is breached, there's another line of defense. This is particularly useful in scenarios where Valkey instances are exposed to the internet or interconnected across different networks.
• Additionally, trusted network can simplify access control management, especially in large-scale deployments. Instead of configuring permissions for individual users or applications, you can simply whitelist trusted IP ranges or subnets. This can significantly reduce the administrative work.
• Furthermore, A trusted network feature acts as a fail-safe mechanism, ensuring that even if ACLs are misconfigured, access is still restricted to trusted networks, minimizing the impact of misconfigurations.

Additional information

• The server IP subnet mask works as a reference and classifies the intended client is trursted or not. In case of Tenent's clients, will maintain a list of Tenent IPs to be trusted. Remaining all client will be rejected. Also open to take other solutions.

Alternatives you've considered

• Firewall installation or proxy server installation.

[madolson]

I would be for implementing something like this. I know that practically every group or company that has a devops team that "manages" Redis would have liked this type of feature, so seems reasonable to add to Valkey.

Furthermore, Some company regulatory frameworks or industry standards may explicitly require the use of trusted network configurations as part of compliance measures. Implementing this feature ensures adherence to such requirements, adding an extra level of assurance. A trusted network feature acts as a fail-safe mechanism, ensuring that even if ACLs are misconfigured, access is still restricted to trusted networks, minimizing the impact of misconfigurations.

We know much about this specifically?

[hwware]

My apologies for late reply, I retract the cliam regarding the standards and frameworks. Thanks!

[zuiderkwast]

Sounds good to me. Can we have a more exact suggestion, like config name and value, before we make a decision?

[PingXie]

+1. I agree this is a very valid "management" problem to solve.

@hwware I think we should also consider the impact of NAT when it comes to the detailed design.

Once we have the mechanism to tell "trusted" clients based on their IPs, I think we should also consider evaluating some server polices differently, such as maxclients. There have been cases where the client applications exhausted maxclients leaving no connections to the admin.

[daniel-house]

Perhaps a client coming from a "trusted" location should be allowed to connect at all times?

If the management-port #497 were available we wouldn't need to worry about this.

[madolson]

Perhaps a client coming from a "trusted" location should be allowed to connect at all times?

What does this mean? I'm not sure what it means to be able to connect at all times. Are you suggesting we have a separate thread serving it, or just that it doesn't need to provide authentication, or that it will be accepted even during a command?

[daniel-house]

Sorry, that is quite vague. It was intended to be in the context of "max clients has been reached".

Perhaps it should be possible to configure it so that a client coming from inside a trusted network should be allowed to connect even though max-clients has been reached.

[hwware]

Sounds good to me. Can we have a more exact suggestion, like config name and value, before we make a decision?

1. The feature's major goal is enabling capability to decide whether the client is from trusted network or not, I would like to add config parameter name as "trusted-addresses". clients from the list of IP addresses will be trusted.

Syntax: trusted-addresses <IP> <IP> <IP> <IP> ...
ex: trusted-addresses 10.0.0.1 10.0.0.5 12.0.0.5

2. In case of client unix socket, we can consider the client upon following check, if "c->flags & CLIENT_UNIX_SOCKET" is true then its trusted otherwise would be considered as un-trusted.
3. Other clients to be considered as trusted are connected from local host and client connected from same subnet(Will introduce some new server structure field as hostMachineNetMask/host_machine_netmask , hostMachineIp/host_machine_ip).

[zuiderkwast]

@hwware I like this idea. But often in small setups, a web server and a valkey server are located on the same machine. Then it's not perfect that clients on localhost are automatically trusted and can get passed the maxclients config.

[daniel-house]

How about another configuration property: trust_localhost? The default would be false.

Or perhaps something stronger, allow_clients_from_trusted_sources, with a default of false, so that this is not a breaking change. Then, by default, the system acts exactly as it does today.

Or something more complex, such as multiple configuration properties, so that you can specify exactly which sources are trusted (e.g., trust_localhost, trust_local_subnet, and trust_unix_socket).

[madolson]

trusted-addresses 10.0.0.1 10.0.0.5 12.0.0.5

I sort of like the idea of this, but allow this to be more flexible. Maybe support: trusted-sources 10.0.0.5 10.0.0.* unix, to support either a specific IP, a subnet sdk, or a unix domain socket. I would prefer a single configuration option, but we could do multiple to. I suppose overlap with the bind addresses, but also include unix as an option.