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

authentication operations should use special Nexus context #846

Closed
Tracked by #419
davepacheco opened this issue Apr 1, 2022 · 0 comments · Fixed by #912
Closed
Tracked by #419

authentication operations should use special Nexus context #846

davepacheco opened this issue Apr 1, 2022 · 0 comments · Fixed by #912

Comments

@davepacheco
Copy link
Collaborator

davepacheco commented Apr 1, 2022

Right now, the session lookup and silo user fetch operations are not protected with authz. I think the reason is that they're used during request authentication -- before we know who the user is, and certainly before we know what privileges they have.

A better solution might be to use a special Nexus context for this, whose only privileges are to read from those tables (and maybe update the session table, in order to refresh and invalidate sessions). I think this would be pretty straightforward:

  • create a new built-in user for this purpose ("external-api-authenticator"?)
  • create a new built-in role for this user -- it could be at the "Fleet" level ("fleet.authenticator")
  • create a new built-in role assignment that grants "fleet.authenticator" on the global Fleet to the built-in user "external-api-authenticator"
  • update omicron.polar: define custom resources for SiloUser and ConsoleSession, with the usual permissions, and say that "read" and "modify" permissions are granted to anybody with "fleet.authenticator" on the parent fleet
  • update nexus/src/authz/api_resources.rs to include types for the new Polar resources
  • update the code paths in datastore.rs:
  • at Nexus startup, create an OpContext for the "external-api-authenticator" user
  • use this OpContext inside the external API authenticator

This way, at the datastore and below, these are just like any other resource. At the caller, we're basically saying that the authentication steps access to the database as Nexus itself, and once we've validated the user, we switch to using their context for everything. I think this accurately reflects what's really going on and maintains least-privilege.

This should also allow us to remove DataStore::pool() and use DataStore::pool_authorized() everywhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant