UCP: Support super user login without TiDB
Description
Now TiDB Dashboard can only be logged in with existing TiDB node. However for pure TiKV deployments there is no TiDB node, makes user unable to use TiDB Dashboard.
For such scenario, we need to provide alternative login method: supply a super user login username and password. The username and hash of the password is stored in PD etcd so that multiple PD nodes can share the same authenticator.
Even if there is a TiDB node in the cluster, when log in use super user, TiDB related functionalities like Statements should not be available (since they requires a valid TiDB connection).
Score
- 1680
You will be rewarded with extra 300 points if UI is also implemented.
Mentor(s)
- @breeswish
Contact the mentors: #tidb-challenge-program channel in TiDB Community Slack Workspace
Recommended Skills
- Security
- etcd
- Go web programming
@breeswish
- How to distinguish the two login mode?
- Is TiKV mode password changeable?
@SSebo
- User should be able to choose the login mode at UI. Currently there is already a field for this in the API:
is_tidb_auth. - Yes. User should be able to update the password in UI after a successful sign in. However this functionality is not the scope of this UCP issue. You only need to cover the sign in part in this UCP.
@breeswish mentor
- How to set initial password? like in some config file ? or some constant string?
- What etcd path is proper to store this hashed password? the golang backend just fetch this path and check user input hashed is equal this pass?
- In what situation user will login without TiDB, and there is a tidb instance in cluster? Is it mean that if user login with this super password, the ability to use TiDB related functionalities is disabled? no matter there is TiDB node or not ?
Hi @SSebo
How to set initial password? like in some config file ? or some constant string?
There should be no initial account (and no initial password). i.e. by default user is not allowed to sign in use TiKV mode.
The account and password can be manually set via a binary command. We can implement the following utility library functions:
clearInternalAccount()Removes the internal account from an etcd endpointverifyInternalAccount(username, password) -> boolVerifies the internal account according to the given credential.resetInternalAccount(username, password)Creates or resets the internal account according to the given username ans password.
Then, we can:
- modify
pd-ctlto provide a command to create / reset, or clear the internal account. - modify
tidb-dashboardcmd to provide the same functionality as well. The new usage can be:tidb-dashboard start- start the dashboard server (current functionality)tidb-dashboard user clear- deletes the internal accounttidb-dashboard user reset --username X- resets the internal account
What etcd path is proper to store this hashed password? the golang backend just fetch this path and check user input hashed is equal this pass?
I suggest the following path:
/dashboard/internal_account/user: The username/dashboard/internal_account/pass: The bcrypt hash of the password
In what situation user will login without TiDB, and there is a tidb instance in cluster?
For example maybe all TiDB instances are down.
Is it mean that if user login with this super password, the ability to use TiDB related functionalities is disabled? no matter there is TiDB node or not ?
Yes. Also technically we cannot invoke TiDB related commands as well, since they requries a valid TiDB connection. We cannot establish a TiDB connection without knowing the credential of TiDB account.
tidb-dashboard user reset --username X - resets the internal account so we still need to reset password 😆
@SSebo new password need to be input
/pick-up-challenge
@SSebo pick up issue success
@breeswish mentor,
- Is there a related issue in PD? or I just modify it and create a PR then ask you to review ?
- Where should I start to add a new sub command to PD? Should I add a
dashboardsub command inpdctl?
@SSebo There is no related issue in PD, since it is only a subtask of this UCP. You can also change the PD part after everything else is finished, since the change to pd-ctl should be trivial. You may introduce commands like "dashboard user clear" and "dashboard user reset
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Although corresponding UCP task is finished, we still have some work to merge it to master. So I'm going to keep this issue open.
Is there any plan to move it on?