Skip to content

[ENH] - Improve fine-grained access control #6

Description

@kcpevey

Feature description

First, is there a description of the access controls we currently have? My understanding:

  • All Nebari users have access to everything deployed on the Ray cluster.
    • This includes deploying and creating things.
    • One user can destroy things deployed by another user
    • We have no way to control who has access to the cluster or who can access models deployed on the cluster.

Next, we need to define what RBAC we WANT. My understanding here is that it is fairly straightforward to give a group of users full access to everything on a cluster and much much harder to given a group of users access to certain things deployed on a single cluster.

Because of this, it seems to me that a good short term goal would be to implement separate clusters for different groups in keycloak. That would be an acceptable next step for my use case.

Notes from Ken:

  • NOTE: There is no RBAC right now. All nebari users have access to the ray cluster.
    Need to research whether there is even a concept of granular access control within Ray Serve. The authentication we use right now is "front door" only to the dashboard. Anyone in JHub with the URL to the Ray Serve cluster (i.e. the ...svc.local) is able to hit the full API
  • This opens two questions:
    • Are there API auth controls we can implement (both API and dashboard) in Ray Serve?
    • To fill any gaps, do we need to build API endpoint auth (from within the K8S cluster/JHub) and/or do we approach fine-grained permissions by deploying multiple Ray Serve clusters (see related concern below r.e. Python environments)

Value and/or benefit

Admins can control who has access to clusters. Groups/teams of users would have to share resources and there will be a required level of "trust" across the group.

Anything else?

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    Priority

    None yet

    Start date

    None yet

    Target date

    None yet

    Size

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions