-
Feature
-
Resolution: Unresolved
-
Critical
-
None
-
None
-
False
-
None
-
False
-
Not Selected
-
0% To Do, 100% In Progress, 0% Done
Feature Overview
Support Policy management of the ValidatingAdmissionPolicy feature available and fully supported as of OpenShift 4.17
Goals
- Display ValidatingAdmissionPolicy through the "Discovered policies" user experience
- Enable users a multi-cluster experience around ValidatingAdmissionPolicy
- Allow users to leverage the RHACM Governance dashboard as a single pane of glass for their various Policy engines
Use Cases
- As a VAP user, I can go to the Discovered policies dashboard and view the VAPs I have deployed across the fleet
- Name
- Engine - Kubernetes (w/ icon)
- Kind - ValidatingAdmissionPolicy
- Response action - spec.validationActions (in ValidatingAdmissionPolicyBinding, Deny/Warn/Audit)
- Source
- Severity (same as how Gatekeeper works)
- Cluster violations - will be empty
- As a VAP user, I can select a given ValidatingAdmissionPolicy, and drill in to see the clusters it is deployed to
- Cluster name
- Severity
- Source
- Violations - will be empty
- As a VAP user, I can select a given ValidatingAdmissionPolicy instance deployed on a cluster, and drill in to see more details
- View VAP YAML
- View VAPB YAML
- View resource YAML for the referenced resource used (VAP - spec.paramKind, VAPB - spec.paramRef)
- As a Gatekeeper user, I can understand the relationship between a Gatekeeper constraint that delegates to a ValidatingAdmisssionPolicy and the VAP instance itself
Questions to answer
- Complexities in using Search as a back-end for VAP, given that ValidatingAdmissionPolicy is applied with ValidatingAdmissionPolicyBinding resources?
- VAPs set to audit mode, will have VAP audit events stored in the control plane audit logs; does RHACM need to intersect with work being performed in the multi-cluster logging space with Observability to integrate here?
- VAPs do not have a violation status, therefore there will never be any violation statuses listed in the UI/UX, will this be odd / confusing?
- This is probably okay, because VAP was not intended to provide any type of resource preview experience to figure out which resources would (eventually) violate the VAP before actually deploying it
- If Gatekeeper is being used to deploy a VAP under the hood; should the resulting VAP be hidden from the top-level Discovered policies table?
- If so, when does it make sense to list the VAP (if at all) in the UX?
Requirements
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 |
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)?
- relates to
-
ACM-14837 Implement discovered polices support for VAP
- Closed