lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(spec): project-config: apiserver is the only project authorization point

Browse source 
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) <noreply@anthropic.com>
This commit is contained in:
Rongsong Shen 2026-10-13 04:17:04 +00:00
parent 88ca983f43
commit 33edbeeaf0
Signed by untrusted user: rshen
GPG key ID: 80533536B0EB651C
2 changed files with 12 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

14
.kiro/specs/project-config/brief.md
View file

@ -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`).

7
.kiro/specs/project-config/requirements.md
View file

@ -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.