search

oxidecomputer / omicron

Omicron: Oxide control plane
Mozilla Public License 2.0
252 stars 40 forks source link

OMDB should participate in authz #6600

Open hawkw opened 2 months ago

hawkw commented 2 months ago

Currently, OMDB uses the test user's authz actor, which does not have authorization to view a number of objects, such as instances that don't belong to it. This means that many OMDB commands currently run unauthenticated queries, either requiring OMDB commands to reimplement queries that exist in nexus-db-queries, or requiring nexus-db-queries to provide both authenticated and unauthenticated versions of its queries...which creates an opportunity to accidentally misuse the unauthenticated queries elsewhere.

Instead of having OMDB do an end-run around the entire authn/authz system in these cases, it would be much better to give it its own user that has the required access on all silos.

davepacheco commented 2 months ago

More precisely: the test user that omdb currently uses is a type of silo user in the "default-silo" silo. They have "fleet admin", but that privilege doesn't grant users the ability to look at many resources inside other silos. (See #1681 for more context on this.) Any silo user would have this problem.

Assuming we do want to have this debugging tool that can access everything in the database (which seems reasonable at this point), I'd probably explore using a built-in user (rather than a silo user) to do this. This would involve:

  1. Adding a new built-in user USER_OMDB. It'll look at lot like USER_INTERNAL_API. We'll need to define it similar to that one.
  2. Add it to the test at the bottom of the file, too.
  3. Add a role assignment granting it fleet admin (again like USER_INTERNAL_API).
  4. Make sure it gets loaded by adding it to this array.
  5. Add a constant for it similar to USER_INTERNAL_API.
  6. Add a policy rule for it similar to USER_INTERNAL_API that grants it access to all silos.
  7. Change omdb to create an OpContext with this user.

You can find all this (and anything that I missed) by looking for USER_INTERNAL_API.

I would actually consider adding two users: one that's read-only and one that's read-write. Have omdb use the readonly one unless --destructive is passed. See #4805.

hawkw commented 2 months ago

I may take a crack at wiring this up once I finish with waves hands around, but if someone else gets to it first, please feel free to!