WIP Password auth design doc

[jubrad]

Motivation

Tips for reviewer

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

[SangJunBak]

Regarding closing off the internal port for Cloud in the cloud sync:

• We should consider Teleport too since i think it uses some internal port?
• Are we able to easily disable this for the emulator?

[jubrad]

Option A) - preferred
We should consider adding confimap syncing as a self-managed replacement for LD for system vars. If we do this we can probably drop the need for mz_system (in self-managed) and just close off the internal port for self-managed, perhaps not even start it up.

Option B) - backup

• We need to evaluate other mz_system capabilities and ensure that it is not needed for any other purposes.
  If mz_system is needed then we may need to optionally allow external port login for mz_system with a password.

[alex-hunt-materialize]

We should consider Teleport too since i think it uses some internal port?

Teleport prefers mutual TLS, and we've actually gone out of our way to disable it. It's been on the roadmap for a long time to get that working, but never got to it.

[DAlperin]

Here are my thoughts on implementation:

• A system table for storing sensitive role data like the (hashed and salted) password of a role
  • In the future we could transition this to secrets once those are supported for self managed
• We will expand the adapter::Client surface area to expose an API to the protocol layer which can be used to exchange a username and password for a role
  • when running in cloud we will continue to use frontegg and this codepath will be unexercised
• we will do the same adapter call or equivalent in tower middlewares for the http endpoint

The rest of it as laid out in the doc makes sense to me

[jubrad]

On system users... We might be able to pass in a bootstrap user that is also considered internal/system. This user should be considered superuser and internal user and it's password should come from a k8s secret. The k8s secret passed in can be used as it's password secrets reference in the catalog.

[SangJunBak]

Still not clear to me the flow of setting up auth. In my head, it looks like:

1. As they initially set up via the helm chart, orchestratord will have the env variable to set the password of the mz_system user. This is probably configurable via the helm chart?
2. Once the user deploys the materialize CR, orchestratord will pass that env variable in order to start the environment with an mz_system type user
3. The user can now login via that user and add more roles

Does that sound correct? Then we just make it a limitation that a user can't use the Console unless there's a registered role. In the Console, we'll most likely need the following information

• Is (password) auth enabled?
• Does there exist an authenticated user?
  But I'm also confused how the Console might receive this information if we can't query the database to begin with.

Should also consider the migration path from self managed customers without auth to customers with auth.

[alex-hunt-materialize]

This may need an updated Materialize CRD to add a new field for the name of the secret.

[alex-hunt-materialize]

@SangJunBak +1 to everything you said.

But I'm also confused how the Console might receive this information if we can't query the database to begin with.

Maybe we can pass that to the console also? Maybe through an env var? That gets a bit tricky, since I think we update the balancers and console immediately upon getting an updated Materialize, while only updating environmentd if we trigger a rollout. Perhaps this logic needs to change, but that may be difficult too.

[jubrad]

Still not clear to me the flow of setting up auth. In my head, it looks like:

1. As they initially set up via the helm chart, orchestratord will have the env variable to set the password of the mz_system user. This is probably configurable via the helm chart?
2. Once the user deploys the materialize CR, orchestratord will pass that env variable in order to start the environment with an mz_system type user
3. The user can now login via that user and add more roles

Does that sound correct? Then we just make it a limitation that a user can't use the Console unless they have . In the Console, we'll most likely need the following information

• Is (password) auth enabled?
• Does there exist an authenticated user?
  But I'm also confused how the Console might receive this information if we can't query the database to begin with.

Should also consider the migration path from self managed customers without auth to customers with auth.

Your initial flow is correct!

Then we just make it a limitation that a user can't use the Console unless they have .

Unless they have what?

The standard auth for postgres has login and non login users see pg_authid. For logins, one can first check that the role allows login then compare passwords. This would be done fully on the server side. I imagine we want to enable rolcanlogin if a password is set, and by that just check to see password.is_some() or something.

[SangJunBak]

@jubrad

Unless they have what?
Ah my bad. Unless there's a registered role! Edited.

The standard auth for postgres has login and non login users see pg_authid.

But I mean in order for the Console to query pg_authid via the HTTP API, wouldn't they need to be authenticated?

[SangJunBak]

Maybe we can pass that to the console also? Maybe through an env var? That gets a bit tricky, since I think we update the balancers and console immediately upon getting an updated Materialize

@alex-hunt-materialize and with the current design, an env variable won't do much good given the Console's already built by the time orchestratord installs the console pod. There's currently no way for orchestratord to edit build variables for the Console, which I think we should fix!

[jubrad]

Unless they have what?
Ah my bad. Unless there's a registered role! Edited.

The standard auth for postgres has login and non login users see pg_authid.

But I mean in order for the Console to query pg_authid via the HTTP API, wouldn't they need to be authenticated?

Console shouldn't need to query pg_authid. It should just need to attempt to connect using username and password. If the role isn't a login role or there's a password mismatch that should all be handled server side. To determine if auth is enabled it could just attempt to run a query and, on failed login, route to the login box, or we can install a configurable endpoint on NGINX that console can hit to tell it what kind of auth it should attempt to use.

[SangJunBak]

LGTM on my end! Thanks for writing all this out!

[jasonhernandez]

My "hard requirements"

1. Set the minimum iteration count >=200,000.
2. Do not allow lockouts by default.
3. Log successful and failed login attempts by default.

I've made some additional comments and recommendations for discussion / consideration. Thanks for writing this all up and the consideration in this design.

[ptravers]

should this include a threat analysis?

[jubrad]

should this include a threat analysis?

This will be a self-managed only feature which will be scoped different for security audits. I'll leave it up to @jasonhernandez to sort out how we deal with this.

[jasonhernandez]

Thanks for setting a 400k iteration count as the default. This looks like a good v1 design to ship.