-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Database access through WebUI #49979
Conversation
This pull request is automatically being deployed by Amplify Hosting (learn more). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First pass.
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! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
first pass
{({ validator }) => ( | ||
<form> | ||
<DialogContent minHeight="240px" flex="0 0 auto"> | ||
<FieldSelectCreatable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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:
|
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
…onal/teleport into gabrielcorado/pg-webui-changes
* feat(web): add database terminal access * chore(web): make explict type cast * refactor(web): code review suggestions * chore(web): fix lint errors * refactor(web): lint errors * refactor: code review suggestions * refactor(web): filter wildcard options from connect dialog * chore(web): lint * refactor(web): code review suggestions
* Add PostgreSQL REPL implementation (#49598) * feat(repl): add postgres * refactor(repl): change repl to use a single Run function * test(repl): reduce usage of require.Eventually blocks * refactor(repl): code review suggestions * refactor(repl): code review suggestions * test(repl): increase timeout values * fix(repl): commands formatting * refactor(repl): send close pgconn using a different context * fix(repl): add proper spacing between multi queries * test(repl): add fuzz test for processing commands * Add WebSocket handler for WebUI database sessions (#49749) * feat(web): add websocket handler for database webui sessions * refactor: move common structs into a separate package * refactor(web): use ALPN local proxy to dial databases * feat(repl): add default registry * refactor(web): code review suggestions * refactor: update repl config parameters * refactor: move default getter implementation * feat(web): add supports_interactive field on dbs * refactor: code review suggestions * refactor: update database REPL interfaces * chore(web): remove debug print * feat: register postgres repl * refactor(web): update MakeDatabase to receive access checker and interactive * chore(web): remove unused function * Database access through WebUI (#49979) * feat(web): add database terminal access * chore(web): make explict type cast * refactor(web): code review suggestions * chore(web): fix lint errors * refactor(web): lint errors * refactor: code review suggestions * refactor(web): filter wildcard options from connect dialog * chore(web): lint * refactor(web): code review suggestions
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).