lablup / lablup/backend.ai

Delegated ownership (owner_id) for v2 Deployment APIs

Open
#12,154 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
670
Forks
183
Avg merge
15h 13m
Merged PRs (30d)
368

Description

### Background

The v2 Deployment REST/GQL APIs have no way to act on behalf of another user. BA-5901 originally proposed adding owner_access_key (string) to the v2 DTOs, but we adopt the user-UUID-based delegation pattern instead, matching the owner_id field already used by v2 session creation (CreateSessionInput.owner_id). Access-key-based delegation is considered legacy and will not be extended.

The data model is already prepared for this: EndpointRow has a session_owner column distinct from created_user, and route-driven inference session creation already builds the session draft identity from session_owner (sokovan/deployment/deployment_draft_builder.py), so per-owner resource policy enforcement at session enqueue time already works. The v2 adapter currently hardcodes session_owner to the creator (api/adapters/deployment/adapter.py).

### Goal

An authorized caller can create and manage deployments on behalf of a target user by specifying owner_id (UUID) in the request body. Inference sessions spawned for the deployment routes are owned by the target user, and resource policies are computed against the target user, exactly as if they had created the deployment themselves.

### Scope

- Add owner_id: UUID | None to v2 Deployment request DTOs (common/dto/manager/v2/deployment/request.py): CreateDeploymentInput, UpdateDeploymentInput, revision DTOs (e.g. AddRevisionInput), and delete DTOs.
- RBAC-based authorization check that the caller is allowed to act on behalf of the target user. Legacy helpers (check_if_requester_is_eligible_to_act_as_target_\* / query_userinfo query_on_behalf_of path) must not be used.
- Resolve the delegated owner and store it as EndpointRow.session_owner instead of the hardcoded creator, so the existing sokovan path (DeploymentContext / DeploymentSessionDraftBuilder) computes resource policies against the owner. The exact layer for owner resolution is an implementation decision.
- Keep created_user as the actual caller for audit purposes; only session_owner reflects the delegated owner.
- Propagate the field through the full v2 stack: DTO, adapter, REST handler, GQL type, client SDK v2, CLI v2.

### References

- BA-5901: original request (owner_access_key on v2 Deployment and v2 VFolder DTOs) — superseded by the owner_id approach for the delegation field.
- v2 session delegation precedent: CreateSessionInput.owner_id (common/dto/manager/v2/session/request.py) and SessionService.enqueue_session owner resolution.

JIRA Issue: BA-6470

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.