## Description Kyverno has deprecated legacy `Policy` / `ClusterPolicy` resources and has published a planned removal path for the Kyverno 1.20 timeframe. Big Bang's kyverno-policies package still ships legacy `ClusterPolicy` resources for package-provided policy enforcement. This epic tracks the follow-on work after &578: finish feasible CEL-era policy migrations, validate the migrated policy set, and prepare a safe default-change plan. The goal is to preserve expected policy intent while reducing long-term reliance on legacy Kyverno APIs. ## Customer or Stakeholder Sponsor (Please do not include CUI or any sensitive program or personnel names) No single customer sponsor is named for this follow-on epic. The work supports Big Bang users and platform stakeholders who rely on the kyverno-policies package for Kubernetes policy enforcement and compliance-oriented guardrails. ## Value to user of BB Big Bang users get a managed path through Kyverno's policy API transition without losing expected package-provided policy coverage. This reduces lifecycle risk for users who expect Big Bang's Kyverno policies to continue enforcing the same security intent as the underlying Kyverno APIs change. ## Requirements/Scope - Migrate remaining eligible legacy policies to CEL-era Kyverno policy types. - Keep CEL policy behavior behind explicit chart values until cutover is approved. - Maintain coexistence between legacy and CEL policies during transition. - Continue repeatable CLI, Chainsaw, Helm, and CI validation patterns from &578. - Validate the CEL policy set in agreed Big Bang environments. - Document known behavior drift, unsupported mappings, and deferred policies. - Prepare the default-change and legacy-retirement plan. ## Out of Scope - New policy requirements unrelated to legacy-to-CEL migration. - A hard removal date for all legacy policy support before validation and release approval. - Unrelated Kyverno package cleanup unless required for migration safety. - Changing default behavior without a separate approved implementation issue/MR. ## Duration Targeted for ~"PI::Q3", with final timing dependent on migration complexity, validation results, and release planning. ## Team ~"team::Empire" Coordination may also involve Big Bang release, security, and platform stakeholders for validation and cutover planning. ## Dependencies - &578 completed as the initial migration/proof epic. - Remaining migration, validation, cutover, and cleanup issues moved or created under this epic. - Kyverno package CI lanes for legacy and CEL policy validation. - Availability of agreed Big Bang validation environments. - Stakeholder agreement before changing default policy behavior. - Any related PolicyException or additional-policy support work needed for practical CEL adoption. ## Risks - Some legacy behavior may not map cleanly to CEL policy types. - Validation may reveal false positives, missed exclusions, or performance concerns. - Cutover timing may need to shift based on release calendar, Kyverno behavior, or downstream readiness. - Maintaining legacy and CEL lanes during transition adds temporary CI and review overhead. - Retiring legacy support too early could disrupt users. ## Acceptance Criteria - Remaining eligible policies have CEL equivalents, or a documented defer/skip reason. - CEL policy tests run in the agreed validation lanes. - Known behavior drift and migration caveats are documented. - A cutover plan exists for making CEL policies the preferred/default path. - Any default behavior change is gated by explicit stakeholder approval. - Legacy cleanup is either completed after cutover approval or tracked separately. ## Related Issues and/or Epics - &578: Initial Kyverno CEL migration epic - &609: PolicyException replacement via `bb-common`, where relevant, belongs to ~"team::Product Improvement" - Follow-on migration, validation, cutover, cleanup, and release-documentation issues ## How this epic maps to Big Bang OKRs This epic supports Big Bang goals around secure, supportable platform capabilities and reduced lifecycle risk in core packages. It keeps Kyverno-based policy enforcement viable as Kyverno moves toward CEL-era policy APIs, and it gives the team a path to reduce long-term parallel maintenance once the migration is validated. ## How does this proposed work benefit the enterprise using Big Bang and/or end user SRE? Enterprise users and SREs keep a managed path for Big Bang's package-provided policy enforcement as Kyverno changes the underlying policy APIs. The intended outcome is continuity: preserve expected policy intent, validate the new implementation in realistic environments, and avoid surprising users with an unproven default change. ## How does this benefit the internal Big Bang team The internal team gets a clearer path to complete the CEL migration and eventually stop maintaining duplicate legacy and CEL implementations. Any default behavior change or legacy retirement requires a separate approved implementation issue/MR after validation evidence is available.