Review the CRCPLAN parent feature for additional context, including the feature overview, goals, user stories and use cases, acceptance criteria, designs, dependencies, risks, assumptions, pending questions and documentation callouts.

Summary and goal

Description of what we're building, the end goal and how we'll go about it.

RBACv2 will require using Kessel for access checks, because V2 Roles and RoleBindings will not translate to V1 access lookups.

We also need fine grained access meta-authz checks, to prevent escalation of privilege. This is required both in V1 (because of dual write) and in V2 (native).

Acceptance Criteria 

These conditions must be met for the epic to be considered complete. This provides a detailed definition of scope and the expected outcomes, written from a user's point of view.

1. Access configured in V2 is enforced in V2 API calls
2. Access configured in V2 is NOT enforced in V1 API calls or reflected in V1 access queries
3. Queries to Kessel utilize service-to-service authentication via OAuth
4. V2 API calls are responsive (Existing SLOs maintained, if there are new SLOs/what they will be is TBD)
5. Users cannot bind roles to resources they don't have access to bind to (through V1 or V2)

See summary table:

Checklist

Open Questions

Capture any open questions and resolutions related to the epic goal or acceptance criteria. Add any additional details, questions or decisions that need to be made or addressed. 

What are the expected SLOs for these new endpoints? Do we put everything together with existing SLOs?