Context

This is a foundational modernization and de-risking initiative that moves SWATCH off the legacy, unsupported RBACv1 system onto the modern, secure Kessel RBACv2 platform. This migration is the hard prerequisite for the entire CRCPLAN-307 feature roadmap, specifically workspace-level reporting capabilities.

The SWATCH service is currently 100% dependent on RBACv1 for authorization, which blocks all subsequent phases of the Kessel migration and prevents delivery of any new customer-facing features.

Primary Goals

To execute a "like-for-like" migration, replacing all RBACv1 authorization calls with equivalent RBACv2 calls, achieving authorization parity with zero functional changes for the end-user.

The migration is "done" when:
• All authorization logic in SWATCH uses the RBACv2 Policy Decision Point (PDP) access checks
• The service continues to function as-is, using the existing org_id passed in the x-rh-identity header
• All dependencies on the RBACv1 service are fully removed and decommissioned

Acceptance Criteria

• All authorization logic in SWATCH uses the RBACv2 Policy Decision Point (PDP) access checks
• Zero production calls are made from SWATCH service to the legacy RBACv1 service
• Service continues to function identically using existing org_id from x-rh-identity header
• Unleash feature flags enable safe toggling between RBACv1 and RBACv2 systems
• All auth paths validated: SSO, ServiceAccount, x509/SAML via Turnpike
• 100% regression testing passes under both RBACv1 and RBACv2 configurations
• All dependencies on RBACv1 service are fully removed and decommissioned

Scope

In Scope:
• Discovery and auditing of all RBACv1 touchpoints
• Onboarding SWATCH service to Kessel platform
• Refactoring all internal application logic from RBACv1 checks to RBACv2 PDP calls to achieve auth parity
• Implementing Unleash feature flags for safe deployment and rollback capabilities
• Validating all requests function correctly using existing org_id from x-rh-identity header
• Validating correct functionality and security for all auth paths (SSO, ServiceAccount, x509)

Out of Scope:
• Any changes to the SWATCH data model (workspace_id associations are the next, separate initiative)
• Building new CRCPLAN-307 user-facing features
• Complete removal of RBACv1 from the platform (broader decommissioning is a separate platform-wide initiative)

Implementation Phases

Phase 1 - Discovery (Audit): Complete audit of all RBACv1 interactions and finalize implementation plan. Investigate all "Open Questions" including 3scale migration path and authentication mechanism parity.

Phase 2 - Feature Flag Implementation: Deploy Unleash toggles for safe RBACv1/RBACv2 switching without blocking regular releases.

Phase 3 - Logic Refactoring: Replace RBACv1 calls with RBACv2 PDP calls, controlled by feature flags, ensuring logic remains based on org_id.

Open Questions & Discovery Required

• RBACv1 Interaction Audit: Full audit mapping every interaction between SWATCH and RBACv1, including indirect interactions via 3scale and direct backend business logic queries
• 3scale / API Gateway Migration Path: Technical plan for re-configuring 3scale to validate against Kessel instead of RBACv1
• Authentication Mechanism Parity: Migration path for all current auth methods (SSO, Service Accounts, x509/SAML via Turnpike)
• Internal vs. External Endpoints: Authorization impact confirmation on both internal and external API endpoints

Success Metrics

• Technical: 100% of SWATCH authorization via Kessel v2 PDP
• Technical: Zero legacy RBACv1 service calls in production
• Deployment: Feature flags enable zero-disruption toggling between systems
• Functional: All existing org_id-based auth logic passes regression testing under both configurations
• Business: Next initiative (workspace data model changes) becomes unblocked

Links & References

• Supporting Epic: CRCPLAN-307 Subscription Management Onboarding to Kessel
• Draft Permissions PR: rbac-config/pull/648
• Technical Initiative PRD: RBACv1 to RBACv2 Migration PRD