[WIP] [ENH] - Add User table to database#975
Draft
peytondmurray wants to merge 18 commits intoconda-incubator:mainfrom
Draft
[WIP] [ENH] - Add User table to database#975peytondmurray wants to merge 18 commits intoconda-incubator:mainfrom
User table to database#975peytondmurray wants to merge 18 commits intoconda-incubator:mainfrom
Conversation
✅ Deploy Preview for conda-store canceled.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #930.
Description
This pull request adds a
Usertable to the database with the intent of replacing theNamespaceRoleMappingsystem for managing user permissions.Roleenum type to replace current role permissioning inconda-store. Users can have different roles for different environments:NONE(no access to environment),VIEWER(can view an environment),EDITOR(can edit an environment), andADMIN(administrator for an environment). Integer access levels are also assigned to each of these, with higher values representing greater levels of access; this allows you to do comparisons likeRole.EDITOR < Role.ADMIN.UserandRoleBindingtables added to database. EachUserhas zero or more associated entries on theRoleBindingtable which define the level of permissions theUserhas for each environment. When a new user is created, the role bindings passed toconda-storeget translated into entries in theRoleBindingtable, which stores the pattern for each role binding. For example if a user is created with the following role bindings:This will produce two rows in the
RoleBindingrow: one withRoleBinding.role == Role.VIEWERand another withRoleBinding.role == Role.EDITOR. The first row matches any environment namedfooin any namespace starting withenv, and the other matches any environment in thehomenamespace.alembicreadme about how to generate database migrations forconda-store, since there was none.script.py.makothat would cause new autogenerated migrations to failUserentries (and associatedRoleBindingentries are created when the user sends a successful POST to/login/.schema.AuthenticationTokenhas been updated to include auser_namekey for use byconda-store. No password is stored currently.Note this will require changes for Nebari to pass usernames for the users as part of the token to conda-store.
To do
UserandRoleBindingtablesuser_namefield toschema.AuthenticationTokenso thatconda-storecan distinguish users. Keycloak will need to do this too!conda_store_server.api.list_environmentsPull request checklist