-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
-
False
-
-
False
-
Not Selected
Feature Overview
As of Kyverno v1.14 (April 2025) and v1.15 (July 2025), the monolithic ClusterPolicy is being superseded by specialized, CEL-based (Common Expression Language) policy types. This move aligns Kyverno more closely with native Kubernetes ValidatingAdmissionPolicy and improves performance.
For RHACM, this means the Governance and Search components must be updated to recognize these new kinds to ensure compliance reporting and resource discovery remain accurate.
In Kyverno ClusterPolicy is being deprecated. You need to switch to the 5 other policy types.
- ValidatingPolicy
- MutatingPolicy
- GeneratingPolicy
- DeletingPolicy or Cleanup - validate all these CRD names
- ImageValidationPolicy
All new types use the API group policies.kyverno.io/v1alpha1 (moving to v1 in Kyverno 1.17).
| Policy Function | Cluster-Scoped CRD | Namespaced CRD |
| Validation | ValidatingPolicy | NamespacedValidatingPolicy |
| Mutation | MutatingPolicy | NamespacedMutatingPolicy |
| Generation | GeneratingPolicy | NamespacedGeneratingPolicy |
| Cleanup / Deletion | ClusterCleanupPolicy | CleanupPolicy |
| Image Verification | ImageValidatingPolicy | NamespacedImageValidatingPolicy |
RHACM Search
- Indexing: The Search collector must be updated to index these new kinds. If the collector uses a whitelist of CRDs, these must be added to ensure they appear in the RHACM console.
- Relationships: Search should maintain the relationship between these policies and the resources they affect (e.g., a ValidatingPolicy linked to the Pods it governs).
...
Goals
make RHACM Discover feature compatible with latest Kyverno changes
This Section: Provide high-level goal statement, providing user context
and expected user outcome(s) for this feature
- …
Requirements
This Section: A list of specific needs or objectives that a Feature must
deliver to satisfy the Feature.. Some requirements will be flagged as MVP.
If an MVP gets shifted, the feature shifts. If a non MVP requirement slips,
it does not shift the feature.
| Requirement | Notes | isMvp? |
|---|---|---|
| CI - MUST be running successfully with test automation | This is a requirement for ALL features. |
YES |
| Release Technical Enablement | Provide necessary release enablement details and documents. |
YES |
(Optional) Use Cases
This Section:
- Main success scenarios - high-level user stories
- Alternate flow/scenarios - high-level user stories
- ...
Questions to answer
- ...
Out of Scope
- …
Background, and strategic fit
This Section: What does the person writing code, testing, documenting
need to know? What context can be provided to frame this feature?
Assumptions
- ...
Customer Considerations
- ...
Documentation Considerations
Questions to be addressed:
- What educational or reference material (docs) is required to support this
product feature? For users/admins? Other functions (security officers, etc)? - Does this feature have a doc impact?
- New Content, Updates to existing content, Release Note, or No Doc Impact
- If unsure and no Technical Writer is available, please contact Content
Strategy. - What concepts do customers need to understand to be successful in
[action]? - How do we expect customers will use the feature? For what purpose(s)?
- What reference material might a customer want/need to complete [action]?
- Is there source material that can be used as reference for the Technical
Writer in writing the content? If yes, please link if available. - What is the doc impact (New Content, Updates to existing content, or
Release Note)?
