security function basic extended readonly user automately switch to dba user(write privilege)

[402309718]

when I try to test auth fuction I found basic extended with AuthenticationMethod=multi,I use readonly user login to non-leader node,but it switch the writable user ,I login to th leader node ,it shows readonly

about redirect this part whether exists some problem,and if possiable it better add logout icon and add some group ,role

[shlomi-noach]

Hi,
I'm not sure I understand the exact problem, actually. And what setup are you using? If that orchestrator/raft? (in which case most traffic does indeed get auto-routed to the leader?).

if possiable it better add logout icon and add some group ,role

If you want groups/roles then you should not use Basic or Multi authentication method. That's not what they're for.

Right now orchestrator does not support ldap; the common solution is to put it behind apache or nginx or whatever reverse proxy you work with, such that they do the authentication. See https://github.com/github/orchestrator/blob/master/docs/security.md

[402309718]

Hi guy,it deployed with raft
I use multi just diff dba operator and other maintainer not writtable
it is that I login use auth ,but if i want to switch to readonly user in the same web broswer,I can't manually logout,maybe broswer saves the cookie，in a period of time always the the user logined before and then I restart all the orchestrator instance it turns out that sometime readonly user ,some time readonly user and I should closed the window and reopen it

[shlomi-noach]

maybe broswer saves the cookie

That's how Basic Auth works. I might be able to look into it in the future.

[andrein]

when I try to test auth fuction I found basic extended with AuthenticationMethod=multi,I use readonly user login to non-leader node,but it switch the writable user ,I login to th leader node ,it shows readonly

about redirect this part whether exists some problem,and if possiable it better add logout icon and add some group ,role

I think I'm hitting the same issue. Our setup is as follows:

• 3 node cluster with raft + sqlite.
• Authentication configured in multi-mode.

If we log in with the admin user on any node, we have full privileges and the follower nodes proxy our requests to the leader, as expected.

If we log in with the readonly user on the leader node, we have read only privileges, as expected.
If we log in with the readonly user on any of the follower nodes, we have read-write privileges instead of read-only privileges.

@shlomi-noach I suspect this commit has something to do with this. It looks like every request to a follower node is proxied to the leader with elevated privileges, enabling read-write access through the known readonly user with no password.

[shlomi-noach]

If we log in with the readonly user on any of the follower nodes, we have read-write privileges instead of read-only privileges.

Thank you for this analysis.

I suspect this commit has something to do with this.

I think thta commit is unrelated: it only sets up the initial credentials between client and whichever orchestrator node responds. If the situation is as you describe, then the problem is with orchestrator itself relaying the request.

[andrein]

@shlomi-noach can you take another look at this line? d374876#diff-781f3fb2f9ee523020bb7940288434b98c8942f08a297b670b8af90da234d5d3R37

I read that as "set the credentials from the config for every request that's proxied to the raft leader". Am I reading it wrong?

[shlomi-noach]

Thank you, I think you may be right. I haven't touched this part of the code for years now and have gone out of touch. I'm gonna need some time to regain the context and focus, though, and think of the correct solution (unless you are able to propose the correct path forward, that is).

[shlomi-noach]

#1349 is merged and is supposed to solve this issue.

[shlomi-noach]

@402309718 @andrein would either of you be able to confirm #1349 fixed the issue on your env?