[NEW] Trusted/un-trusted client feature
hwware opened this issue · comments
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.
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?
My apologies for late reply, I retract the cliam regarding the standards and frameworks. Thanks!
Sounds good to me. Can we have a more exact suggestion, like config name and value, before we make a decision?
+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.
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.
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?
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.
Sounds good to me. Can we have a more exact suggestion, like config name and value, before we make a decision?
- 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
- 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. - 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).
@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.
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).
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.
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
@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.
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.
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.