# ADR-0001: Unified Permission Model ## Status **Proposed** (under review). Date: 2026-07-10. scope: the generic resource API (`/api/v1/resources/...`) and ServiceAccount/Controller token issuance (the `token` subresource). It does not change how `rise project create`, `rise deployment create`, or other typed-table-backed CLI commands work; those converge onto this model automatically once their tables migrate onto the generic resource store, which is separate, already-planned work (`ROADMAP.md` §4, Typed-object migration). ## Context Rise today has several disjoint authorization mechanisms, each with its own code path. The generic resource API is operator-only: access is gated on membership in the `auth.operator_users` config allowlist, with no finer granularity. The typed APIs (projects, groups, deployments, …) each carry their own per-endpoint ownership and membership checks, with `auth.admin_users` bypassing them wholesale. Controllers authenticate separately and are authorized for status/finalizer writes through each `ResourceDefinition`'s `allowed_status_controller_ids` allowlist. ServiceAccounts get tokens through trust-policy-gated token exchange. Five subject populations, five ways of deciding "may this caller do this." Almost none of this surface is load-bearing yet. The generic resource API's only production use today is seeding the default `Organization` resource from config, and controller authentication is entirely unused. This design therefore carries no backwards-compatibility constraints on the resource-store API or on controller authentication: where the model below conflicts with the current surface, the surface changes — breaking changes are acceptable and preferred over compatibility shims that would bake in tech debt before there is anything to be compatible with. The requirements come from the multi-tenancy split: three distinguishable tiers — platform operator, org admins, org users — with per-org *asymmetric* restrictions. The operator must be able to impose a restriction on one specific org (a compliance-restricted customer). Within each organization where they are an admin, an org admin has every authority not removed by that platform ceiling; the same User may independently be an admin in several organizations. Org admins must be able to delegate access further, but never beyond their own boundaries. And it should be *one* runtime-configurable mechanism covering Users, Groups, ServiceAccounts, Controllers, and Operators alike — not five code paths that happen to agree. The design below was converged through multiple independent adversarial-review rounds; its wording is deliberate, particularly around the security-sensitive edges (label-write gating, token minting, operator bootstrap). ## Decision Every actor in Rise — a person, a group, a CI service account, a controller process, or a platform operator — is a **subject**. Every subject's access to every resource is decided the same way, by the same evaluator, regardless of what kind of subject it is. Resources live in a tree — an Organization contains Projects, and a Project contains Environments, Deployments, and other children (e.g. Environment `env-prod` under Project `app` in the org `acme-corp`). Access is granted by binding a **Role** (a named bundle of permissions — "can update Deployments, can read Environments," built from `verbs` like `get`/`update`/`delete`) to a subject, placed at some point in that tree. A binding's grant applies to everything at or below where it's placed, and — optionally — can be narrowed further to only the resources carrying a specific label. A subject's effective access on a resource is the combination of everything its applicable bindings grant, **minus** every applicable Deny retained for that caller's tier. Among retained statements, Denial always wins over allowance — there is no "more specific wins" precedence between ordinary bindings. Platform Denies apply to everyone except operators; org Denies apply to ordinary org members and workloads but are ignored by current admins of that org (§5). This is what lets the platform cap an org's admins while also letting those admins impose a lower ceiling on their ordinary population. After tier filtering, a restriction is just one more `Deny` folded into the same combination, never a separate capping step on top of it. A **restriction** ("cap") is itself just a `Deny` binding, folded into the same Deny-wins combination as every other binding while retaining its binding placement as provenance. An operator may place a platform Deny instance-wide or scope it to one org; an org admin may place an org Deny to narrow ordinary subjects in that org without narrowing current admins. There is one further rule, applied only at the moment of a write: whoever authors a grant — binding a Role to a subject, or editing a Role's own definition — must already hold everything they are handing out. The check compares net before/after EffectivePolicy, so it also catches authority exposed by removing a Deny or changing admin status; you cannot hand out authority outside your own current effective boundary. Every request starts from current authorization facts in the database — no policy snapshot is baked into a token, and any memoization is confined to that one immutable request snapshot (§5), so tightening a cap or narrowing a Role takes effect immediately for everyone relying on it. This is what makes revoking a Role exactly as effective as revoking a token before it expires — but only for the identity the token belongs to: narrowing what a ServiceAccount itself can do immediately narrows every outstanding token for it. Revoking the separate grant that let someone *mint* that token in the first place does not reach back and affect a token already issued (§7). Ownership works through this same mechanism, not a separate one. A resource can carry a label — `rise.dev/owner: group:platform` or `rise.dev/owner: user:u-01jz…` — naming the group or person it belongs to. The platform ships one built-in rule: whoever that label names automatically gets an owner-level Role on the resource. That rule is the entirety of what "ownership" is — the engine itself has no ownership concept; remove or replace the rule and the word means nothing, or means whatever the replacement says. Nothing about that rule is hardcoded to any specific label key — it's ordinary Role/binding data, and any organization can replace it with their own version using the exact same tools they'd use for any other grant. Because relabeling a resource can silently redirect who holds that owner-level Role, writing such a label goes through the identical check as writing a binding directly: you can only redirect access you already hold. The numbered sections below (§1–§10) are the concrete design this plain-language model compiles down to. ### 1. Subjects Five kinds of subject exist, in two groups. **Org-agnostic — User, Controller.** A single identity can legitimately hold different roles in multiple different organizations: a person is a member of two customers' orgs with different access in each; a single Controller process reconciles resources across many orgs. Nothing about the subject's identifier ties it to one organization. A binding for one of these kinds has a normalized `scope` (§4) — either one specific org, or a wildcard (`"*"`) meaning "the default for every org this identity touches, unless a more specific binding exists for that org." **Org-native — Group, ServiceAccount.** These exist within exactly one organization by construction: a Group has one owning org, and a ServiceAccount is created and lives directly under an org (`serviceaccount:acme-corp/ci-bot`) — a sibling of Project in the resource tree, not nested under any one Project. This is deliberate: a ServiceAccount's reach comes entirely from what it's bound to via ordinary RoleBindings (§4), which can span any number of Projects/Environments in its org; tying its identity to a single "home" Project would suggest a relationship that has no bearing on what it can actually do, and would couple its `effectiveLabels`-inherited attribution (§6.1) to whichever Project happened to parent it. The org is baked into the identifier itself. A **static** binding (a literal, fixed subject — §4) for these kinds either omits an explicit `scope` (normalized to the subject's own Organization scope) or, if one is supplied, it must lie within the subject's own org. In particular, explicit `scope: "*"` is invalid for a static org-native subject: a wildcard in the bound Role's `kinds` still ranges only within the binding's scope and does not make an org-scoped binding reach root-scoped kinds. A **dynamic** binding (a subject template — §4, §6.3) has no concrete subject to infer an org from until it is evaluated against a specific resource; §6.3 states how its resolved subject's org is determined in that case. **Canonical subject identifiers.** Authorization never operates on an unparsed string. One shared `SubjectId` type accepts exactly these concrete forms: ``` user: controller: group:/ serviceaccount:/ org: system:authenticated system:operators ``` `` and `` use the generic resource API's canonical resource-name grammar. Empty components, extra `/` or `:`, dot segments, query/fragment syntax, and non-canonical encodings are rejected; there is no permissive fallback interpretation. A literal User, Controller, Group, ServiceAccount, or `org:` in a binding must resolve at write time to an existing Rise resource (including resources created in the same atomic transaction). The two `system:` forms are virtual and follow the additional authoring restrictions below. Only exact dynamic forms declared by the closed template grammar may contain a marker: kind-fixed templates such as `group:${ref.name}` and `user:${ref.name}`, plus the typed `${ref.subject}` template defined in §6.1. Arbitrary interpolation syntax is rejected when the binding is written. Dynamic substitution produces a concrete canonical `SubjectId` and is parsed again at evaluation time, failing closed if invalid. For an org-native template the matched resource supplies `` as defined in §6.3, so `group:${ref.name}` on an acme resource resolves to `group:acme-corp/` rather than to an incomplete literal. **Subject records and their relationships are built-in resources.** All persisted identity, membership, and authentication-policy objects use the existing built-in `rise.dev/v1alpha1` API group; there is no separate `authorization.rise.dev` group. The entire `rise.dev` API group is reserved for platform-owned built-ins, including future kinds; extension `ResourceDefinition`s must use another group. Placement is fixed by kind: | Kind | Parent | Purpose | |---|---|---| | `User` | root | Stable human identity and non-authoritative profile fields | | `UserIdentity` | `User` | One external SSO `(issuer, subject)` mapping | | `Controller` | root | Stable org-agnostic workload identity | | `ControllerTrustPolicy` | `Controller` | One accepted external issuer/audience/claims policy | | `Group` | `Organization` | Org-native group identity | | `GroupMembership` | `Group` | One name-bound membership marker for a `User` | | `ServiceAccount` | `Organization` | Stable org-native workload identity | | `ServiceAccountTrustPolicy` | `ServiceAccount` | One accepted external issuer/audience/claims policy | The separate trust-policy kinds are intentional: a generic kind has exactly one declared parent, so one `TrustPolicy` kind cannot be parented under both Controller and ServiceAccount without violating the store's exact-parent invariant. Likewise, Group membership is one child resource per edge rather than an array in `Group.spec`: this avoids whole-object lost updates, gives each membership its own grant-gated lifecycle/audit identity, and supports lookups in both directions. A `GroupMembership` is an empty marker whose immutable `metadata.name` must equal the canonical name of an existing User when the membership is created. The ordinary per-parent resource-name uniqueness rule therefore permits at most one edge for a User in a Group. Changing the member is a delete plus create, so adding the replacement User passes the ordinary membership grant gate. Membership itself is boolean for authorization — any descriptive membership role is ordinary metadata and never a second permission system. **Owner references are optional lifecycle metadata, not authorization ownership.** Generic resources may carry `metadata.ownerReferences`: UID-authoritative typed references to other resources that supplement, but never change, the resource's structural parent or URL. Admission requires each reference's kind, canonical name, and UID to resolve to the same live resource; garbage collection follows the UID, so deleting and recreating the same name never transfers lifecycle ownership. Deleting an owner initiates finalizer-respecting deletion of its dependents. `blockOwnerDeletion` defaults to `false`; when explicitly true, that dependent retains the owner's aggregate cascade finalizer until it is collected. Owner-reference graphs must be acyclic. Owner references confer no permissions, do not participate in subject expansion, label inheritance, or policy evaluation, and are never inferred or stamped by the generic API. A `GroupMembership` may omit owner references, in which case deleting its named User leaves the marker in place and recreating that User name deliberately reactivates the name-bound membership. Alternatively, it may carry exactly one owner reference, which must identify that same User; deleting that User then garbage-collects the membership. Backend-managed JIT or directory synchronization should attach this reference when it owns the membership lifecycle, avoiding zombie membership markers. An operator creating durable policy by hand may omit it intentionally. In both cases the membership's structural parent remains its Group, so deleting the Group also deletes the membership. **User names are stable generated identifiers, not email addresses.** A User gets an immutable, collision-resistant DNS-safe resource name such as `u-` (with the store's ordinary uniqueness constraint as the final authority). The generic resource-name grammar remains unchanged and does not admit `@`; relaxing it for one identity kind would either weaken every resource path or require kind-specific metadata-name parsing in the core. `User.spec` may carry presentation fields such as `displayName` and `primaryEmail`, but email is mutable, case-sensitive in troublesome ways, and non-unique across issuers, so it is never a subject key and Rise never auto-links accounts by email. `UserIdentity.spec` carries the authoritative external `issuer` and `subject`; that pair is globally unique among live UserIdentity resources. Issuers must already use their canonical URL spelling, including the no-trailing-slash convention; admission rejects aliases instead of silently repairing an authentication identifier. Both kinds also carry a platform-managed `spec.active` boolean, defaulting to `true`. An inactive User cannot log in and every already-issued token for that User fails authentication. An inactive UserIdentity blocks login through that exact upstream identity and is excluded from operator-selector matching, but does not invalidate sessions established through the User's other identities. These fields are governed resource data, but shipped policy does not let Users edit their own identity records. UI/CLI surfaces resolve and display email/name while bindings, references, URLs, and audit records use the canonical User name. Literal subjects, `roleRef`s, and Group memberships are deliberately **name-bound**: deleting and recreating an identity or Role under the same canonical name makes existing policy refer to the replacement, matching Kubernetes RBAC's name-based references. Credentials add a separate immutable binding. Every persisted User, ServiceAccount, and Controller has a store-assigned UID, and every Rise-issued token carries both the canonical `sub` and that UID in `rise_uid`. Authentication requires both values to identify the same live, enabled resource. Recreating `serviceaccount:acme/ci` may intentionally reactivate name-bound RoleBindings for the replacement, but every token issued for the old UID fails immediately. Dynamic label subjects follow the same name-bound policy semantics. Optional owner references affect lifecycle only: they remain UID-bound and can remove a membership before a same-name User replacement appears, but never change which User a surviving membership names. **Deferred constrained product operation for Project ServiceAccounts.** Generic `create`/`delete` on `rise.dev/ServiceAccount` remains ordinary RBAC authority and is shipped only to org admins and operators; it may intentionally exercise the name-bound behavior above and is not implicitly transformed into a second grant-gate rule. A future user-facing Rise operation will preserve today's "create a ServiceAccount for this Project" flow as a trusted, fixed-shape compound operation authorized against that Project. In one transaction it allocates a fresh collision-resistant canonical ServiceAccount name that the product flow never reuses, stores any friendly requested name as presentation data, creates the Organization-owned ServiceAccount, and creates only the platform-defined Project-scoped bindings and trust-policy data for that flow. The product-created identity does not receive an ownership label that would incidentally expose generic deletion; its lifecycle remains behind the constrained operation. The caller supplies no arbitrary Role or RoleBinding policy and need not hold generic permission to create those resources; instead, the compound operation applies §5's effective-delta subset check to the resulting ServiceAccount policy and rejects any bundle outside the caller's current capped EffectivePolicy on that Project. Its paired deletion operation disables or removes the identity and cleans up only the flow-owned authorization data; the retired canonical name remains unavailable to the product flow. These are constraints on the future design; its route, authorization tuple, execution shape, implementation, and conformance case are deferred to ADR-0002/ROADMAP and do not block this ADR's initial conformance suite. Trust-policy resources contain public matching configuration (issuer, audience, required claim constraints), never private signing keys or bearer credentials. UserIdentity and workload trust-policy writes are ordinary governed resource writes, with their schemas and the authentication-specific validation in §7 applied before persistence. `org:`, `system:authenticated`, and `system:operators` remain virtual predicates and have no corresponding identity row; an Operator remains an active User with at least one live, active UserIdentity selected by restart-loaded configuration. **Operator** is a platform-wide root identity selected by configuration. Each process loads an immutable set of `(issuer, subject)` pairs from `operatorIdentities` at startup; it does not resolve those pairs to a frozen UID set. After a credential resolves to User UID `U`, `U` is an operator iff `U` is active and any live, active `UserIdentity` child of `U` has an exact pair in that configured set. The configured identity is therefore a lookup selector for the User, not a requirement that the current login used that same identity: logging in through any active secondary UserIdentity already attached to `U` yields the same User UID and operator status. Interactive login provides the bootstrap path. After validating an enabled upstream IdP credential, Rise looks up its exact `(issuer, subject)`, including inactive live rows. An inactive mapping, or an active mapping whose parent User is inactive, fails authentication and is never treated as unknown for JIT provisioning. If no live mapping exists, one authentication-plane transaction creates a generated User and that UserIdentity; a unique-index conflict caused by concurrent first logins retries by loading the winning mapping. This includes a pair whose previous mapping was deleted: deletion is unlinking, not durable deactivation, and a later valid login provisions a fresh User and UserIdentity with a fresh UID. Old tokens therefore never revive. Durable disablement uses `active: false`; operators should normally deactivate Users or identities rather than delete them. The new User has no org authority by default, but if the new identity pair is in `operatorIdentities`, the same login immediately qualifies the User as an operator. Consequently deleting a configured mapping revokes the old User's operator expansion only until the next valid login recreates the pair; durable operator removal requires deactivating that live UserIdentity or removing the configured selector and restarting/draining all instances. This fixed JIT operation is the configuration-rooted exception to ordinary grant-gated identity linking. It never attaches an unknown identity to an existing User: a genuine secondary identity must be linked through an explicit governed flow, and Rise never infers account equivalence from email or profile fields. Once attached, every active identity authenticates as the same active User UID. Plain OAuth does not define end-user identity claims, so an OAuth-only upstream needs a provider adapter that supplies the same stable issuer/subject identity contract. Email is never an operator selector. The configured selector set is not hot-reloaded: changing it takes effect only after restart and revocation is complete only after every API instance using the old configuration has been drained. UserIdentity rows remain live authorization facts, however; adding, activating, deactivating, or deleting a configured identity under a User changes that User's operator status on the next request in every running process, subject to the JIT recreation rule above. What changes is how operator status is *expressed*: rather than a hardcoded bypass branch in the evaluator, operator status is membership in one reserved subject, `system:operators` (a `system:`-prefixed name is reserved for platform-recognized pseudo-subjects, never an ordinary User/Group/ServiceAccount/Controller row). The platform seeds exactly one binding for it: ``` subject: system:operators scope: "*" roleRef: { kind: PlatformRole, name: system-admin } # a PlatformRoleBinding (§3) ``` where `PlatformRole/system-admin` allows every verb on every main resource and every registered subresource (§2). An operator's request runs through the *same* evaluation algorithm as anyone else's (§4 steps 1–3) — no separate code path. One thing is special-cased for any request whose membership expansion (§4 step 1) includes `system:operators` — i.e. any request by a current operator: the Deny-wins union of steps 1–3 is overridden, so no `Deny` collected in step 1 can reduce an operator's effective access. This is load-bearing because a cap is itself a `Deny` binding (§5): an operator caps every other subject, including org-admins, but an operator's *own* request ignores every `Deny` — otherwise an operator could accidentally lock themselves, and everyone else, out by placing an instance-wide cap that only they can author, with no one above an operator able to fix it. The granter-subset half of the write-time grant gate (§5) needs no special-casing at all: since `system:operators` always holds every main-resource and subresource permission, any grant an operator hands out trivially satisfies `⊆` their own effective permissions. **`system:` names are reserved, and `system:operators` is never a binding target.** The `system:` prefix is reserved, enforced at both subject creation and binding-`subject` authoring: an unrecognized `system:`-prefixed subject (anything but the platform-recognized `system:operators` and `system:authenticated`) is rejected wherever it appears. Among the recognized names, `system:operators` may *never* be named as the `subject` of an ordinary binding — only the platform-seeded bootstrap binding above targets it; an ordinary `RoleBinding` or `PlatformRoleBinding` whose `subject` is `system:operators` is rejected at write time. Otherwise an org could author a `{Deny: * on *}` binding catching operators and lock them out of an org with no in-model recovery — the exact state §1 exists to prevent. (`system:authenticated` and `org:` remain ordinary group predicates a binding may target — §4's list authorization and general org-wide grants use them, independent of §9 — bounded by the recipient boundary below.) **Membership never replaces a caller's own identity.** When User `user:u-01jz…` makes a request, that remains the caller's subject regardless of which UserIdentity authenticated it. What differs is **membership expansion** (§4 step 1): evaluation considers not only bindings targeting the User directly, but also bindings targeting a current Group and, when any live, active UserIdentity child matches restart-loaded `operatorIdentities`, `system:operators`. Group and operator membership are live instances of the same expansion rule. Since the only binding targeting `system:operators` grants `system-admin`, the User's combined policy includes every main-resource and registered-subresource permission, unioned with whatever they separately hold. Deactivating or removing the matching UserIdentity revokes that expansion on the next request; changing profile email or logging in through another already-linked identity has no effect. A configuration change additionally requires restart and draining old processes. The default ownership binding (§6.2) similarly resolves either the User directly or one of their Groups; Group-targeted ownership reaches each member through this same expansion. **Group subjects.** Two reserved group forms exist beyond persisted Group resources: `system:authenticated` — every authenticated subject, of any kind — and `org:` — every subject belonging to that organization: its org-native subjects (Groups, ServiceAccounts) and its User members alike. A User belongs to `org:` iff they are a current member of at least one Group owned by that org **or** are directly targeted by a qualifying org-admin RoleBinding (§5). The latter is the bootstrap edge that lets the first administrator govern a newly created organization without inventing a magic Group; it is policy data, not a second general membership mechanism. Removing a User's last Group tie and last direct admin binding removes that membership live. An ordinary org `RoleBinding`, including one directly naming `user:`, is intersected with this boundary, so a group-less, non-admin User receives no org-authored grant. To grant ordinary org-private access, first place the User in a Group. An operator may deliberately reach a group-less User through a scoped `PlatformRoleBinding`, outside org governance. SSO/directory synchronization creates and deletes ordinary `GroupMembership` resources, normally attaching the synchronized User as lifecycle owner so User deletion also removes backend-managed edges. A directory-wide Group is the normal way to make every synchronized User an org member. The synchronizer authenticates with a Rise-issued principal and its membership writes pass the same grant gate as manual writes; mapping an upstream directory Group to an admin-bearing Rise Group therefore requires admin-level delegation authority. ServiceAccount inclusion in `org:` remains deliberate: org-wide grants must reach CI identities too. The absolute `org:` form is useful to an operator binding an org population to a root-scoped resource (§9). Inside an org-parented binding the name is redundant — `system:authenticated` already clamps to that binding's org — but the absolute form retains one meaning everywhere and is not overloaded with relative names such as `org:admins`. **Org bindings target only their own org.** An org-parented `RoleBinding`'s grant to any subject is intersected with live membership in that binding's *own* org — a subject receives the grant only while it is a current member of that org. An org-native subject (`Group`/`ServiceAccount`) whose baked-in org differs from the binding's org is provably foreign and contributes no grant; a `User` subject receives the grant only while a live member of the binding's org through a Group tie or the direct admin bootstrap edge above (so a user in `acme` and `beta` gets an `acme`-scoped binding's grant in `acme` alone, and loses it on leaving `acme`); `system:authenticated` inside an org binding auto-clamps to that org's authenticated members and cannot expose platform-wide. A `Controller` — org-agnostic, a member of no single org — likewise receives no org-binding grant. These semantically inert bindings remain valid, safe policy data and are surfaced by policy auditing rather than rejected synchronously. `PlatformRoleBinding`s are root-placed and normalize to `subjectMembership: Any`, allowing deliberate cross-org or platform-wide operator grants. A PlatformRoleBinding may opt back into contextual containment with `ResourceOrganization` (§4); the seeded ownership binding does so, while RuntimeClass availability and explicit non-member grants use `Any` as appropriate. This bans cross-org sharing through org bindings by construction and prevents contextual ownership from outliving org membership; a first-class tenant-authorable cross-org sharing primitive is deferred (§10). **The binding is data; the operator predicate is derived — deliberately.** `system:operators`'s grant (the binding above) is a stored row, same table as every other binding. Membership is never stored as a separate RBAC record: evaluation intersects restart-loaded `operatorIdentities` configuration with the active User's live, active UserIdentity children. This is forced by the bootstrap problem the Operator concept exists to solve: if the initial relationship required an already-authorized RBAC write, nothing could create the first operator. The configured selector set is the one root of trust originating outside the system Rise governs; UserIdentity rows remain ordinary inspectable resources plus the narrow JIT bootstrap path above. The binding has no equivalent forcing problem — it's never granted by anyone at runtime, only seeded once at bootstrap — so it can safely be data, with one refinement. Being immutable through the ordinary write path (§5's **seeded** Role-ownership tier: no write path can ever modify it, not even an operator) only protects against mutation through this model's own API — it says nothing about a bad migration, a restore from an old backup, or direct database access losing the row entirely, outside any write path this model governs. That residual risk is unacceptable for the one subject with no recovery authority above it. Operator status is a property of the requesting caller, not of any one subject row. Whenever a request's live membership expansion (§4 step 1) includes `system:operators`, the evaluator yields the complete main-resource and registered-subresource policy for that request unconditionally — it ignores every `Deny` collected in step 1 from *any* subject, including a `Deny` targeting the caller's own `user:` identity or any cap binding. No binding can reduce an operator's effective access. The write-time rejection of bindings that target `system:operators` (above) remains as defence-in-depth but is not load-bearing on its own: configured selectors can change across restarts and their matching UserIdentity rows can change live after a binding is written, so the guarantee must hold at evaluation regardless of what `Deny` rows exist. This guarantee is hardcoded in the evaluator — not something solely read from, and therefore losable with, a table row. The row is still materialized alongside that guarantee, purely so the same explain/audit tooling that inspects everyone else's access can inspect this one too without a special case; if it's ever found missing or altered outside the write path, that's healed by re-materializing it, not a live authorization dependency. This mirrors how Kubernetes actually handles `system:masters`: a hardcoded superuser check in the authorizer grants it full access with no ClusterRole or ClusterRoleBinding required at all, *and*, redundantly, an ordinary `cluster-admin` ClusterRoleBinding also binds the same group to the same power as a stored object — kept self-healing (missing permissions/subjects on default, `kubernetes.io/bootstrapping=rbac-defaults`-labeled objects are restored automatically) rather than merely immutable. Every other `system:`-prefixed built-in role (`system:node`, `system:kube-scheduler`, etc.) gets only the self-healing-data half, no hardcoded bypass, because losing one of those is recoverable by whoever holds `system:masters` — the same distinction already drawn above between `system-admin` (nothing above it, needs the hardcoded guarantee) and `org-admin` (recoverable by an operator, doesn't). Kubernetes' authorization decisions are live on every request in both cases, same as this model's throughout (§5); what's actually startup-scoped there is narrower — only the drift-repair of default objects' stored contents, not authorization itself. **Wildcard resolution.** When two bindings target the same `(subject, labelSelector-key-if-any)` pair — one with `scope: "*"` and one with a more specific `scope` — the more specific one **replaces the wildcard outright, for that scope** — it does not merge with it. "Same subject" for this comparison means the same literal subject, or the same subject *template* text; a dynamic binding on `labelSelector: {key: rise.dev/owner}` never collides with one on `labelSelector: {key: rise.dev/squad}`, even if both use the identical template `${ref.subject}` — they are different rules. This comparison is always performed on the binding's authored `subject` field exactly as written — literal `SubjectId` against literal `SubjectId`, or raw template string against raw template string — never on a resolved value: a literal binding (`subject: group:acme-corp/platform`) and a dynamic one (`subject: group:${ref.name}`) never collide with each other, even where the template resolves to that same concrete Group, so a platform-wide dynamic default is never silently discarded just because one particular resource's resolved subject happens to match some unrelated static binding. Where a `labelSelector`'s optional `value` also differs between two otherwise-colliding bindings, replacement is evaluated per-resource, at the same point §4 step 1 collects applicable bindings, not as a blanket scope-wide swap — a `value`-narrowed selector only matches (and so only competes with and replaces a broader same-key selector for) resources whose label actually equals that value; resources carrying any other value never collect the narrowed binding in step 1, so the broader selector continues to govern them, undiminished. This replacement rule applies to any subject (not only Controller) whenever a wildcard `scope` is in play, including the dynamic ownership bindings in §6 — and crucially it applies **across placement tiers**: an org-parented `RoleBinding` may replace a root-parented `PlatformRoleBinding`, which is exactly what lets an org override the platform-seeded ownership default (§6.5), whose default *is* a `PlatformRoleBinding`. What replacement may never do is *subtract a `Deny`*: it preserves every `Deny` statement the superseded binding carried and may drop only the wildcard binding's *Allow* content. That single invariant — not a blanket placement prohibition — is what stops an org from escaping an operator's platform restriction: a restriction expressed as a `Deny` survives replacement regardless of who authored the superseding binding, while an all-`Allow` default (like `resource-owner`, §6.2) remains freely overridable. It exists to keep "what does this rule resolve to, in this org" a single, unambiguous answer instead of an additive combination of whatever bindings happen to apply — the one place bindings do not simply combine (§4 covers the ordinary, additive case). **Accepted risk.** Because replacement is outright rather than merged, an org-specific binding can unintentionally discard everything a wildcard binding provided beyond what the org-specific one restates — e.g. narrowing a shared Controller's wildcard grant in one org for one reason can silently strip that Controller of unrelated capabilities it still needed there. There is no dry-run/impact-preview step (§5's cap-tightening risk acceptance applies equally here) — this is an accepted, unmitigated footgun for both cap tightening and wildcard replacement. The footgun is one of capability *loss* (dropped Allows), not escalation: were replacement to drop the superseded binding's `Deny` statements too, losing a `Deny` would be a privilege *gain* — the escalation direction, not merely lost capability — which is exactly why replacement preserves `Deny` (above). A platform-hard restriction is therefore durable whether an operator expresses it as an operator cap `Deny` (a `PlatformRoleBinding` no org can remove, and whose `Deny` survives replacement anyway) or as a `Deny` statement inside a wildcard binding (preserved through any override); the accepted, unmitigated part is only that an org override can silently drop an operator's wildcard *Allows* — a capability-loss footgun, never a restriction-bypass one. ### 2. Verbs and subresources The ordinary verbs are `get`, `list`, `create`, `update`, and `delete` — Rise's existing action vocabulary — plus **`use`**, the right to *reference* a resource from another resource's fields. `use` is distinct from reading or editing and is checked at write time of the *referencing* resource, against its writer, wherever a `ResourceDefinition` declares a reference (§9). Granting `get` without `use` makes a catalog browsable but not selectable; `use` without `get` allows selection by name without exposing the referenced object's contents. (Precedent: the Kubernetes `use` verb on PodSecurityPolicies.) Like Kubernetes, Rise models a secondary operation as an orthogonal **subresource**, not by inventing a compound verb. An authorization request is therefore `(verb, ResourceKind, subresource?)`: status update is `(update, rise.dev/Deployment, status)`, while delegated ServiceAccount token issuance is `(create, rise.dev/ServiceAccount, token)`. The main resource has no subresource value. Permissions never flow implicitly between the two: `update on rise.dev/Deployment` does not authorize `(update, rise.dev/Deployment, status)`, and a status grant does not authorize the main update endpoint. This keeps authorization aligned with the API route and leaves room for Kubernetes-shaped endpoints such as `logs`, `scale`, and `proxy` without expanding the verb vocabulary into `getLogs`, `updateScale`, and so on. A subresource is an API routing and authorization boundary over a parent resource, not necessarily a second stored object. `status` is a field in the parent kind's schema and is returned by an authorized `get` of the main object; `/status` is the restricted mutation path for that field. `token` is instead a create-only operation that returns a credential without persisting a Token resource. `ResourceDefinition` declares which named subresources a kind supports and which shared handler strategy each uses. Requests for undeclared subresources fail before authorization, and declarations use canonical lowercase names from a closed platform registry for the initial model: `status`, `finalizers`, and `token`. Each registered strategy also declares its supported HTTP/RBAC verbs; for example, `token` accepts `create` but not `get` or `update`, while `status` and `finalizers` accept their defined read/update operations. A Role may contain a broader wildcard, but it can authorize only an operation the registered route actually serves. **`status` follows Kubernetes' split-object semantics.** A kind that declares `status` still defines and stores `status` in the one resource envelope. An authorized main-resource `get` returns the complete object, including status; there is no separately stored `DeploymentStatus` kind. Main-endpoint `POST`/`PUT`/`PATCH`/apply operations ignore proposed status changes and preserve the stored value, while writes through `/status` ignore every change except status. This makes manifests copied from a read safe to apply without overwriting controller-owned observations. Status-only writes do not increment `metadata.generation`, but they do use the normal schema validation, admission, resource-version concurrency, persistence, and audit path. A kind without a declared `status` subresource has no such field-level separation. This separation is generic resource-API machinery, not code every handler reimplements. For a replace, the main strategy restores old status and the status strategy restores every non-status field; patch/apply exclude protected fields while calculating the mutation so the caller neither changes nor acquires field ownership for them. The shared layer then validates and stores the resulting whole object. A `ResourceDefinition` may supply an optional kind-specific validator for legal status transitions, but routing, authorization, projection, merge behavior, concurrency, and persistence remain shared. Rise applies the same machinery to `/finalizers` as a deliberate hardening extension: finalizers remain part of `metadata`, but main writes preserve them and only `(update, ResourceKind, finalizers)` may change them. The target model removes `ResourceDefinition.allowedStatusControllerIds` and the corresponding collection metadata. A Controller is an authenticated subject, so its `status` and `finalizers` access comes solely from ordinary RoleBindings over the registered subresource tuples above. The legacy allowlist remains transitional only until controller requests pass through the unified authorization choke point; it is not a second authorization mechanism in the target API. This ADR standardizes that shared authorization and handler seam, plus the concrete `status`, `finalizers`, and `token` strategies. Streaming, connection, proxy, and virtual-projection contracts needed by possible future `logs`, `proxy`, or `scale` subresources are explored in [ADR-0002](./0002-generic-resource-subresource-execution-model.md). Adding one later does not change the RBAC algebra: it registers a handler and is authorized by the same `(verb, ResourceKind, subresource)` tuple. ### 3. Roles and the Allow/Deny evaluator A **Role** is a named, reusable **policy**: an order-irrelevant list of statements, ``` { effect: Allow | Deny, kinds: ["rise.dev/Deployment"] | ["rise.dev/*"] | "*", verbs: ["update", "delete"] | "*", subresources?: ["status"] | "*" } ``` A `ResourceKind` is the canonical, version-independent `/` pair: `rise.dev/Deployment` or `widgets.example.com/Widget`. An exact value matches one kind; `rise.dev/*` matches every Kind in that API group; bare `"*"` matches every group and Kind. Versions are absent because all served versions of one `(group, Kind)` share authorization. Unqualified Kind strings are rejected, closing the ambiguity allowed by storage, where different API groups may legitimately use the same Kind name. A statement with omitted `subresources` matches only the main resource. A statement with `subresources: ["status"]` matches only that subresource, and `subresources: "*"` matches every subresource registered for the matching kind, but still not the main resource. Consequently, granting `* on *` does not silently grant a subresource registered in the future; a Role that truly needs both writes two statements. The seeded `system-admin` policy does so: ``` { effect: Allow, kinds: "*", verbs: "*" } { effect: Allow, kinds: "*", verbs: "*", subresources: "*" } ``` A subject's access on `(verb, ResourceKind, subresource?)` under a given policy is permitted iff at least one `Allow` statement matches and no applicable `Deny` statement matches — Deny wins after §5's placement-tier filtering. Pure-additive permission sets cannot express subtraction from an open-ended wildcard; a Deny expresses it directly: ``` Allow: * on * Deny: delete on rise.dev/Environment ``` Roles and RoleBindings are data (rows), not compiled match arms — operators and org admins configure who can do what at runtime, no redeploy required. Restrictions (§5) are `Deny`-bearing bindings of this same policy shape, not a separate construct: platform placement caps admins and ordinary subjects, while org placement caps only ordinary org subjects. A Role's own statement list is, like any other resource, ordinarily writable by whoever holds `update` on its kind — but because editing a widely-bound Role changes what every subject bound to it can do, that write is gated the same way a RoleBinding write is (§5). **Two kind pairs, one per placement level.** The resource store's parent model is exact — a kind declares one parent, not a choice of parents — so policy objects come as two same-shaped pairs, the same fork Kubernetes resolves with `ClusterRole`/`Role`: **`Role` and `RoleBinding`** are parented under an `Organization` (org-level policy, authored by whoever holds `create`/`update` there — org-admins by default, further delegable like anything else), while **`PlatformRole` and `PlatformRoleBinding`** are parented at the root (platform-level policy — operator-authored, not by a bespoke rule but because only `system:operators` holds `create` at root under ordinary default-deny). Where this document says "binding" or "Role" without qualification, the statement applies to both pairs alike. ### 4. RoleBindings — targeting a subject to a slice of the resource tree A **RoleBinding** attaches a Role to a subject, at a `Scope`, optionally narrowed by a `labelSelector`. Serialized fields are lower camel case: ``` subject: | subjectMembership: Any | ResourceOrganization # always present after normalization scope: | "*" # always present after normalization labelSelector?: { key: