neon
neon copied to clipboard
neondatabase
User management RFC
Similarly for authentication, I think a small cache of users would suffice, instead of trying to mirror everything in the console.
Hmm. So, if Alice tries to brute force usernames on an endpoint, compute will wake, and Alice can keep it always awake since a non-existent user is always a cache miss. Moreover, if she can somehow get a big enough list of our endpoint addresses, she can try to simultaneously wake them, exhausting all our pre-created k8s nodes so that a new legit compute won't start. That was my main rationale behind the decision to store all roles on the console (probably, I should've written this in RFC itself).
Agree that storing databases in console is optional, and we can wake compute and query it instead to render pages.
In time-travel situations, I don't think we can store a copy of all users and databases at all points in time. Some kind of lazy loading will be needed in that scenario anyway.
I was thinking of the model where the console calls /get_catalog right after branch creation, and then the proxy can authenticate connections against it. So we will store all roles current_number_of_branches times.
Tricky question here is what to do when we want to query historical data by using only connection options (e.g. postgres://<...>?asoftime=12341314) -- there is no branch yet, hence no cached info yet. I can think of several possible behaviors:
- Let any connection spin up a compute and do auth when it will be running. If we will limit free tier users with N simultaneous computes, this behavior will make wake-up-call attack N times worse.
- Do not allow branch/ro-compute creation via connection options, require API call for that. In this model, we can still get away with oneliner for historical connection, e.g.
given that> psql `curl -H 'Auth...' api.neon.tech/projects/rough-queen-833418/get_temp_branch?time=1234`/get_temp_branchwill return a connection string. By that time, compute will be already started, and roles will be available. - Combination of 1) and 2) -- try authorizing against the current state of roles. This will work if your password on the branch is the same. If it is not, then use API. This will work in most cases, but I don't like that there is quite a lot of implicit behavior.
- Actually store all the role changes in the console
I actually think that option 2) could be even nicer/clearer compared to ?options= way. There is less magic, and you know immediately what is happening. Also, URL encoding for :/= in options is quite annoying.
Tricky question here is what to do when we want to query historical data by using only connection options (e.g. postgres://<...>?asoftime=12341314) -- there is no branch yet, hence no cached info yet. I can think of several possible behaviors:
I also thought that we can have an explicit checkbox on the endpoint that it allows time-travel, which automatically implies that it's read-only. After that we can implicitly create a new branch, spin up the compute on it, fetch users, authenticate, use and delete branch when compute is suspended.
We can also set a limit, i.e. if you have a connection to this endpoint @LSN1 and try to connect @LSN2, we will restart the compute to work on the LSN2 and first connection will be dropped.
Similarly for authentication, I think a small cache of users would suffice, instead of trying to mirror everything in the console.
Hmm. So, if Alice tries to brute force usernames on an endpoint, compute will wake, and Alice can keep it always awake since a non-existent user is always a cache miss. Moreover, if she can somehow get a big enough list of our endpoint addresses, she can try to simultaneously wake them, exhausting all our pre-created k8s nodes so that a new legit compute won't start. That was my main rationale behind the decision to store all roles on the console (probably, I should've written this in RFC itself).
Yeah, that would be bad. I don't have a great solution in mind. Caching full list of users is one way, I agree. Another might be some generic DDoS protection, blocking too-frequent attempts from certain IP addresses.
P.S Alice would never do such a thing. Sounds more like Mallory ;-)
yes, my previous message sounds a bit weird :D sorry
#3838 will be merged
Hmmm wait a second, if it's going to be merged in #3848, why did you close it today together with this one ?
Maybe a missclick?
@Ranguna , thanks. Yes, you're right. #3838 should be merged. This one - must be closed.