nebari-dev / nebari-dev/rayserve-pack

[ENH] - Improve fine-grained access control

Open
#6 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Makefile
Stars
1
Forks
4
Avg merge
3d 14h
Merged PRs (30d)
5

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no repository files or tests. Start by researching Ray Serve API and dashboard authentication, including the related concern in issue #2, then compare Kubernetes/JupyterHub endpoint auth with separate Ray Serve clusters tied to Keycloak groups. Done means documenting the supported access-control options and defining a concrete implementation scope.

Written by the indexing model from the issue text.

Assessment

Tech stack
kubernetes
Domain
authentication, authorization, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.