Database access through WebUI #49979
Conversation
gabrielcorado
added
the
no-changelog
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
web/packages/teleport/src/Console/DocumentDb/DocumentDb.story.tsx
Outdated
Show resolved
Hide resolved
web/packages/teleport/src/Console/DocumentDb/DocumentDb.test.tsx
Outdated
Show resolved
Hide resolved
web/packages/teleport/src/Console/DocumentDb/DocumentDb.test.tsx
Outdated
Show resolved
Hide resolved
|
Sorry, I didn't manage to re-review today. I will do it in the morning! |
| {({ validator }) => ( | ||
| <form> | ||
| <DialogContent minHeight="240px" flex="0 0 auto"> | ||
| <FieldSelectCreatable |
There was a problem hiding this comment.
how do we handle wildcard? if no wildcard, it shouldn't be Creatable in my option.
isDisabled={dbUserOpts?.length == 1} will disable if single wildcard?
There was a problem hiding this comment.
When we have a wildcard, the fields will be empty, and users must type it out.
Setting to disable will prevent them from changing the roles (I'm not sure if this will be desired).
There was a problem hiding this comment.
i must have missed it. Where is the logic to remove wildcard from db users?
| <FieldSelect | ||
| label="Database roles" | ||
| menuPosition="fixed" | ||
| isMulti={true} | ||
| onChange={setSelectedRoles} | ||
| value={selectedRoles} | ||
| options={dbRolesOpts} | ||
| /> |
There was a problem hiding this comment.
It might be confusing to users what role selection does.
We should do either or both of the following:
- have a hint/info tooltip that explains a) if no roles are selected, all allowed database roles will be provisioned on connection. b) otherwise, only selected databased roles will be provisioned.
- select all roles in the box by default
I would also move role selection below database name selection. I might even put database name selection before user selection. WDYT?
There was a problem hiding this comment.
I think selecting all roles initially might be better here. We can also always enforce at least one selected (when there are options available).
There was a problem hiding this comment.
About the wildcard for roles, we don't have enough information to decide when to show this box. This would be a combination of the database having auto-user provisioning enabled and not having DAC configured on their selected roles (correct me if I need to include anything here). So, for now, only showing when the roles are available might not cover all scenarios, but it will work for the most part. WDYT?
Also worth mentioning that currently, the database roles information is not available. The web handler changes will add this.
There was a problem hiding this comment.
just some facts
- database roles do not support wildcard
- database roles section is a very niche feature (like I mentioned, even the requestor of this feature might not be using it at the moment)
- database roles and DAC permissions are mutually exclusive
So for simplicity, we could just leave this part out.
If we want to keep it:
So, for now, only showing when the roles are available might not cover all scenarios, but it will work for the most part.
this should be ok, also it's backend's responsibility to make sure the calculation is correct so we don't build more logic in frontend
I think selecting all roles initially might be better here.
I think this would be easiest as well.
We can also always enforce at least one selected (when there are options available).
IMHO not necessary
There was a problem hiding this comment.
@gabrielcorado do you have a branch with all the changes? I'd like to test it locally :)
web/packages/teleport/src/Console/DocumentDb/DocumentDb.test.tsx
Outdated
Show resolved
Hide resolved
web/packages/teleport/src/Console/DocumentSsh/Terminal/Terminal.tsx
Outdated
Show resolved
Hide resolved
|
@gzdunek Update: Both PRs are merged at master. You can try pulling this branch and running it. (You still need a PostgreSQL database access configured). |
|
After talking with @greedy52 we've done a few updates on the connect dialog:
|
Part of #44956 (RFD 0181)
This PR implements the necessary WebUI changes to access PostgreSQL (and other protocols) databases. The flow is very close to the Kubernetes Pod Exec, so the code is highly inspired by it. Here's a simplified version of how the flow looks:
Demo (requires changes from other PRs)
Screen.Recording.2024-12-09.at.22.48.37.mov
(Besides this demo, the PR includes storybooks for all components/pages that have been changed.)
Note
This PR only includes the WebUI changes and won't have any effect without the other related changes: The REPL implementation (#49598) and web handler changes (#49749).