[NEW] Trusted/un-trusted client feature about valkey HOT 15 OPEN

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).

from valkey.

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.

I would like to implement the 1st step: the config parameter only allow to be configured as ip address list because generally,
clients do not connect to the server directly, they should connect through some proxy machines. The ip addresses are limited,

Then 2nd step, I prefer the add more parameter options, the format could be 1.2.3.4/24 or 1.2.3.4 255.255.255.0 unix instead of 10.0.0.*, how do you think? Thanks

from valkey.

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?

from valkey.

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

from valkey.

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

from valkey.

+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.

from valkey.

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.

from valkey.

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?

from valkey.

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.

from valkey.

@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.

from valkey.

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).

from valkey.

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.

from valkey.

@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.

This feature, trusted or untrusted ip address is from server view, even web server or administration server and valkey server are in the same physical machine, valkey server will still check the connected ip address. Most cases it should be configured by system adminstrator. if the web-server is untrusted and on the same physical machine as the Valkey-server and the administrator needs to be a trusted client, then the address of the host must not be in the list of trusted IP addresses, and the administrator need to connect from a trusted address.

from valkey.

Most cases it should be configured by system adminstrator. if the web-server is untrusted and on the same physical machine as the Valkey-server and the administrator needs to be a trusted client, then the address of the host must not be in the list of trusted IP addresses, and the administrator need to connect from a trusted address.

Most cases, but not always. We need to be backward compatible. If we give any superpowers to trusted clients, then we need to make sure that no existing running application is trusted automatically. The default needs to be no trusted IP at all.

If someone runs a webserver from localhost and also connect as admin from localhost, then we can't disable maxclients for both of them based on IP. In this setup, it's better that none of them is trusted and that admin sometimes can't connect because maxclients is reached, than the possibility that the webserver can make infinitely many connections.

from valkey.

I think there is a misunderstanding here. As I read "then the address of the host must not be in the list of trusted IP addresses, and the administrator need to connect from a trusted address", it means that the administrator cannot connect from the same host that is running both the web-server and the valkey-server because that host does not appear in the list of trusted addresses.

Thus, the default is backward compatible, which is to say, nobody is trusted.

from valkey.