nebari-dev / nebari-dev/rayserve-pack
[ENH] - Improve fine-grained access control
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.
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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