From 33edbeeaf03779555ecb02a1e72dd271d836a3af Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Tue, 13 Oct 2026 04:17:04 +0000 Subject: [PATCH] docs(spec): project-config: apiserver is the only project authorization point Production submits always go through the apiserver; harness and direct client-library submits are test tools. The apiserver resolves the project and checks project:submit; the controller records the project and the authorization basis it is given. Direct submits are recorded as given with basis `direct`. Co-Authored-By: Claude Opus 5.5 (1M context) --- .kiro/specs/project-config/brief.md | 14 +++++++------- .kiro/specs/project-config/requirements.md | 7 +++++-- 2 files changed, 12 insertions(+), 9 deletions(-) diff --git a/.kiro/specs/project-config/brief.md b/.kiro/specs/project-config/brief.md index 2aede70d..b8a3eb47 100644 --- a/.kiro/specs/project-config/brief.md +++ b/.kiro/specs/project-config/brief.md @@ -36,7 +36,7 @@ limits cannot be configured end to end, and nothing shows usage per project. environment variables). - **Access check** at submit (user decisions 2026-10-12): an RBAC permission `project:submit`, implied by membership of the project and - grantable by roles (apiserver early check, controller authoritative), with + grantable by roles (checked in the apiserver only: production submits always go through it, 2026-10-12), with a clear error; `cluster_admin` keeps its existing bypass. - **Project admins**: a project's `admins` get every job permission and `project:view` over its subtree, implied by config like membership. Only @@ -116,12 +116,12 @@ projects: `resource-distribution-mapping`, `rbac-persistence`. ## Design questions (RBAC, 2026-10-12) -- RBAC lives in the apiserver; the controller sees only config. Direct - client-library and harness submits bypass the apiserver, so there the - controller can honour membership and `cluster_admin` but not explicit role - grants. Options: the controller trusts an authorization basis passed by - the authenticated apiserver; or explicit `project:submit` grants apply on - the REST path only (documented). +- Resolved 2026-10-12 (user): production submits always go through the + apiserver; harness and direct client-library submits are test tools. The + apiserver resolves the project and checks `project:submit` (membership + and role grants); the controller records the project and authorization + basis it is given and never re-checks RBAC. A direct submit is recorded + as given with basis `direct` (Req 3.13). - The job's authorization basis (Req 3.11) is a new job field: WAL fact and scheduler snapshot must carry it (field completeness, `persistence.md`). diff --git a/.kiro/specs/project-config/requirements.md b/.kiro/specs/project-config/requirements.md index e2c326cc..ef42d720 100644 --- a/.kiro/specs/project-config/requirements.md +++ b/.kiro/specs/project-config/requirements.md @@ -40,6 +40,7 @@ Discovery brief: `.kiro/specs/project-config/brief.md`. Governing rules: `.kiro/ - Submitting under a project is an RBAC permission, `project:submit` (scope type `project`), checked like `queue:submit`. - Membership implies the grant: being a member of P gives an implicit `project:submit` on P only (membership is not inherited). Roles may also grant `project:submit` explicitly (e.g. to service accounts); a `project` scope covers the named projects and their subtrees, as for every `project` scope. - Project admins: a project's `admins` (users and user groups) get an implicit grant of every job permission and `project:view` over the project's whole subtree. Being an admin does not imply `project:submit`. +- In production every job submission goes through the apiserver (REST: `xcecli`, UIs); the harness and direct client-library submits are test tools. The apiserver is therefore the one place that resolves the project and checks `project:submit`; the controller records what the apiserver decided and does not re-check RBAC. - In this stage project definitions, members and admins change only through cluster config, so only the cluster administrator edits them; project admins manage jobs, not the project. ## Introduction @@ -106,7 +107,7 @@ This feature makes projects first-class cluster configuration entities that cont 2. When a job is submitted without a project name and at least one defined project lists a user group the submitter belongs to as default-for, the Cluster shall use the first such project in configuration order. 3. When a job is submitted without a project name and no default-for rule matches the submitter, the Cluster shall use the cluster default project if one is configured, and otherwise the project `default`. 4. The Cluster shall record the resolved project name on the job at submit, show it in the job's details, and keep it unchanged across later configuration changes, failover and restart. -5. The Cluster shall apply the same project resolution to every submit path (REST API, `xcecli`, harness and client library) and to every element of a job array. +5. The Cluster shall apply the same project resolution to every submission through the REST API (`xcecli` and any other client of the API) and to every element of a job array. 6. The Cluster shall identify a project at submit only by its full path name; a name that is only the last segment of a defined project's path (e.g. `cfd` for `eng/hpc/cfd`) is treated as the top-level project of that name. ### Requirement 3: Submit authorization @@ -121,9 +122,11 @@ This feature makes projects first-class cluster configuration entities that cont 6. The Cluster shall not infer membership of a project from membership of its parent, its children or any other project; the implicit `project:submit` of a member covers that project only. 7. The Cluster shall treat a role grant of `project:submit` with scope type `all` as covering every project, and with scope type `project` as covering the named projects and their descendants. 8. Where a user may submit under several projects, the Cluster shall accept the user's jobs under any of those projects. -9. The Cluster shall reject an unauthorized or unknown-project submission before the job is assigned a job ID or recorded, on every submit path. +9. The Cluster shall reject an unauthorized or unknown-project submission before the job is assigned a job ID or recorded. 10. The Cluster shall check `project:submit` in addition to, not instead of, the existing queue permission. 11. The Cluster shall record on the job whether its project was authorized by membership, by a role grant or by the cluster administrator role. +12. The apiserver shall be the only component that resolves the project and checks `project:submit`; the controller shall record the project and authorization basis it receives with the submission without checking them again. +13. When a job is submitted directly to the controller, bypassing the apiserver (harness and client-library test paths, not supported for production), the Cluster shall record the project name as given (an empty name as `default`) with the authorization basis `direct`, without project resolution or authorization; Requirement 5 still applies to the pending job, except the membership hold of 5.2. ### Requirement 4: Open mode when no projects are defined **Objective:** As an operator of an existing cluster, I want clusters without project definitions to keep working as today, so that upgrading does not break existing submissions.