search

Panfactum / stack

The Panfactum Stack
https://panfactum.com
Other
16 stars 5 forks source link

PgAdmin exposed and using SSO #126

Closed wesbragagt closed 2 months ago

wesbragagt commented 2 months ago

Prior Search

What new functionality would you like to see?

The same way we have grafana, Argo and vault interfaces for users to authenticate and interact with those services, it would be super helpful to have PgAdmin hooked up to SSO and vault’s dynamic credentials.

How would you use this new functionality?

This feature would help users to query databases through a web UI without having to install and run the stack repo.

In order to do that they would have to sign-in through the SSO flow and only be provided temporary credentials for the time of the session and also as a default precaution in read-only mode.

fullykubed commented 2 months ago

There are a few concerns that I have with this approach:

  1. pgAdmin4 does not have the authentication hooks required for the full scope of this request. It is possible to add SSO to pgAdmin's webserver, but this authentication will not grant you access to any underlying database. Each user would still need to source credentials from Vault for every database connection via some other process (e.g., the local CLI tool or the Vault web UI) and paste them into the pgAdmin UI.

  2. pgAdmin doesn't strike me as the most secure system. I am not sure what the security implications of running it in multi-user mode will be and I cannot find any documentation on their site describing their security model. I do not think this is a very popular or well-tested deployment scenario. Without doing a deep-dive, I'd worry that this would be creating a threat vector where exposing pgAdmin on the public internet might allow anyone who can access it to have the ability to access the database credentials and sessions of all other users via some yet undiscovered vulnerability (or misconfiguration on my end, given the lack of good documentation).

  3. Submitting raw sql through our ingress system seems like it might trigger our future WAF protections so there would have to be specific carve-outs here and I am somewhat hesitant to punch holes in the default security system unless absolutely necessary.

To summarize: the only ergonomic improvement that this could provide is allowing users to not have to run pgadmin4 locally, but it comes at an unknown security cost. To me, this seems like a dubious tradeoff, but I am open to hearing more thoughts.

Personally, it feels like the existing flow is already fairly streamlined:

  1. Run pf-db-tunnel to establish a network connection and get temporary credentials bound to lifetime of the tunnel.

  2. Use your preferred DB explorer of choice (regardless of whether pgAdmin or something else) and paste the credentials in.

This is very secure, very easy to maintain, and gives users flexibility on what tools they want to use.

wesbragagt commented 2 months ago

@fullykubed the trade-off makes a lot of sense, thanks for looking into it and clarifying reasons against pursuing such feature add.