Skip to content
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

Merged
merged 14 commits into from
Dec 16, 2024
Merged

Conversation

gabrielcorado
Copy link
Contributor

@gabrielcorado gabrielcorado commented Dec 10, 2024

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:

  1. The user clicks the newly added "Connect in the browser" button on the database connect dialog (resources page).
  2. A new tab opens, and the user fills in the database session information (fields are pre-filled with the information from the database). Then, click on the "Connect" button.
  3. The dialog closes, and a terminal starts with the database REPL (as for this version, only PostgreSQL will be supported).
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).

@gabrielcorado gabrielcorado added the no-changelog Indicates that a PR does not require a changelog entry label Dec 10, 2024
@github-actions github-actions bot requested review from avatus and gzdunek December 10, 2024 02:18
Copy link

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-49979.d3pp5qlev8mo18.amplifyapp.com

Copy link
Contributor

@gzdunek gzdunek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First pass.

@gzdunek
Copy link
Contributor

gzdunek commented Dec 12, 2024

Sorry, I didn't manage to re-review today. I will do it in the morning!

Copy link
Contributor

@greedy52 greedy52 left a 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
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we have a wildcard, the fields will be empty, and users must type it out.

Screenshot 2024-12-13 at 11 26 10

Setting to disable will prevent them from changing the roles (I'm not sure if this will be desired).

Copy link
Contributor

@greedy52 greedy52 Dec 13, 2024

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?

Comment on lines 154 to 161
<FieldSelect
label="Database roles"
menuPosition="fixed"
isMulti={true}
onChange={setSelectedRoles}
value={selectedRoles}
options={dbRolesOpts}
/>
Copy link
Contributor

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?

Copy link
Contributor Author

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).

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

@gzdunek gzdunek left a 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 :)

@gabrielcorado
Copy link
Contributor Author

gabrielcorado commented Dec 13, 2024

@gzdunek I pushed a branch with all the changes for this feature to work (gabrielcorado/pg-webui-access-test). The only thing you'll need is a PostgreSQL database configured.

Update: Both PRs are merged at master. You can try pulling this branch and running it. (You still need a PostgreSQL database access configured).

@gabrielcorado
Copy link
Contributor Author

After talking with @greedy52 we've done a few updates on the connect dialog:

  • Never disable the fields. This will prevent users from being able to change the value.
  • Remove wildcard (*) values from the select list.
  • Always select all roles (when available).

@gabrielcorado gabrielcorado requested a review from r0mant December 16, 2024 16:39
@public-teleport-github-review-bot public-teleport-github-review-bot bot removed the request for review from avatus December 16, 2024 16:44
@gabrielcorado gabrielcorado added this pull request to the merge queue Dec 16, 2024
Merged via the queue into master with commit d5c6911 Dec 16, 2024
42 checks passed
@gabrielcorado gabrielcorado deleted the gabrielcorado/pg-webui-changes branch December 16, 2024 17:01
gabrielcorado added a commit that referenced this pull request Dec 16, 2024
* 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
github-merge-queue bot pushed a commit that referenced this pull request Dec 16, 2024
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-changelog Indicates that a PR does not require a changelog entry size/lg ui
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants