Add Users and Groups permissions filters to DaskWorker profiles

[viniciusdc]

Reference Issues or PRs

#979

What does this implement/fix?

This PR includes the ability to restrict users from selecting dask worker profiles based on two factors:

• Explicitly define which user or group will have access to the profile under nebari-config.yaml file:

profiles:
  ...
  dask_worker:
    "Small Worker":
     # New fields (Optional)
      access: yaml # Explicitly defines permission filtering from the yaml
      users: <test-user> # A list of users who will have access to this profile
      groups: <my-group> # A list of groups who will have access to this profile
      ....
      worker_cores_limit: 1
      worker_cores: 1
      worker_memory_limit: 1G
      worker_memory: 1G
...

• Or, by including the dask_profiles attribute for the user or group on Keycloal

profiles:
  ...
  dask_worker:
    "Small Worker":
     # New fields (Optional)
      access: keycloak # Explicitly defines permission filtering from keycloak
      ....

bellow an example of such an attribute for a given user:

This follows the same model that is already in place for jupyterhub profiles.

Put a x in the boxes that apply

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds a feature)
• [ ] Breaking change (fix or feature that would cause existing features not to work as expected)
• [ ] Documentation Update
• [ ] Code style update (formatting, renaming)
• [ ] Refactoring (no functional changes, no API changes)
• [ ] Build related changes
• [ ] Other (please describe):

Testing

• [ ] Did you test the pull request locally?
• [ ] Did you add new tests?

Any other comments?

[viniciusdc]

A few remarks:

1. Deployment Testing Pending: The implementation must still be tested in a live deployment. (I will test on local soon)
2. Inconsistency in Profile Object Standards: There must be more consistency in how profile objects are handled across different environments. For instance, Dask treats profiles as a dict entity, Terraform expects them as a list, and Jupyterlab also uses a list but with unconventional handling. This could be an excellent first issue.
3. Mapper Functionality Check: I confirmed through Postman that the mapper is operational. However, there is an observable delay in updating the scopes.
4. Need for Unit Testing in Configuration Files: Developing unit tests, or mock-ups, for gateway-config.py and jupyterhub python files is essential. These tests should ensure that the configuration objects and methods function as expected, at least from a Python perspective.
5. Upcoming Refactoring for Keycloak Attribute Mapper: The Keycloak attribute mapper will likely undergo refactoring in light of the anticipated new permissions system.

[marcelovilla]

@viniciusdc what's the status of this PR?

[viniciusdc]

Hi, @marcelovilla; thanks for the ping. This was ready for review back then, but there are some changes that I need to make for this work again. As you said, the first step is fixing the conflicts.

[marcelovilla]

@viniciusdc I'll review this once you've had the change to fix the merge conflicts

[dcmcand]

@viniciusdc what is the status here?

[viniciusdc]

Will need to fix this during the weekend