-
Notifications
You must be signed in to change notification settings - Fork 40
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
OMDB should participate in authz #6600
Comments
More precisely: the test user that 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:
You can find all this (and anything that I missed) by looking for 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 |
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! |
As described and suggested in oxidecomputer#6600, create two built-in users to replace the test user for OMDB's purposes. Follows USER_INTERNAL_API and its read-only counterpart. Signed-off-by: Andriy Sultanov <[email protected]>
As described and suggested in oxidecomputer#6600, create two built-in users to replace the test user for OMDB's purposes. Follows USER_INTERNAL_API and its read-only counterpart. Signed-off-by: Andriy Sultanov <[email protected]>
As described and suggested in oxidecomputer#6600, create two built-in users to replace the test user for OMDB's purposes. Follows USER_INTERNAL_API and its read-only counterpart. Signed-off-by: Andriy Sultanov <[email protected]>
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 requiringnexus-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.
The text was updated successfully, but these errors were encountered: