-
Notifications
You must be signed in to change notification settings - Fork 487
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[NEW] Trusted/un-trusted client feature #469
Comments
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.
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 |
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. |
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. |
Syntax:
|
@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: Or perhaps something stronger, 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). |
I sort of like the idea of this, but allow this to be more flexible. Maybe support: |
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
Additional information
Alternatives you've considered
The text was updated successfully, but these errors were encountered: