-
Feature Request
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
None
-
Product / Portfolio Work
-
None
-
False
-
-
None
-
None
-
None
-
-
None
-
None
-
None
-
None
-
None
1. Proposed title of this feature request
Improve Useability of Validating Admission Policies
2. What is the nature and description of the request?
Validating Admission Policies (VAP) are a relatively new feature in Kubernetes that enable the definition of policies using CEL expressions. The major advantage of VAP over conventional policy engines is that it does not require an admissions web hook as it is built into the API server. It includes features to avoid processing policies that are overly complex and would burden the api-server.
This proposal is to close some gaps with VAP that make it difficult and challenging for Enterprises to use, see the the section "Why is this needed?" below.
This proposal includes three components as follows:
- Background Controller. This controller would evaluate VAP policies on a periodic basis by determining all resources on the cluster that match a VAP and performing a `kubectl server apply --dry-run` to determine the impact of the policy. This controller would create and update PolicyReport objects in various namespaces to provide the status of the policies. It could also use annotations on the VAP for additional informational items such as Severity. This process would operate similarly to Kyverno’s Background Scans. Kyverno can also generate reports for VAP which is what this functionality is seeking to replicate.
- CLI. This CLI would use the same code base as the Background Controller and would enable the user to perform a dry run of a VAP without applying it to the cluster.
- User Interface. Create a user interface in either the OpenShift Console, ACM or both to display the status of VAP policies. This needs to be accessible to regular users with appropriate RBAC. While ACM can show the VAP clusters defined on the cluster it doesn’t show the policy violations associated with VAP.
Benefits
- VAP is maintained upstream in Kubernetes and is not a separate project that Red Hat would need to support independently, we benefit from the community.
- Could potentially replace Gatekeeper in ACM reducing the ACM teams maintenance load. Additionally IMHO VAP is simpler to use then Gatekeeper as well since Gatekeeper requires Rego experience. VAP uses CEL which is used in other Red Hat products such as OpenShift Pipelines. This may also require MutatatingAdmissionPolicy to GA in Kubernetes given some customers are using Gatekeeper policies in this fashion.
3. Why does the customer need this? (List the business requirements here)
The downside of VAP is that it is lacking in some critical features that customers would typically be looking for before they can adopt it successfully, specifically:
- Since the policy is evaluated at admission time there is no way to dry-run a policy in an existing-cluster to ensure it will not have negative effects before adopting. Users have to deploy the policy as an info policy and then use “oc apply --dry-run” to determine which resources would violate the policy. This is very cumbersome.
- It lacks easy-to-use reporting capabilities. While VAP can optionally send auditing events an Administrator would have to sift through the audit log for these. Regular users have no way to see violations beyond info or error messages they receive when deploying resources.
- Informational elements such as Severity are not available in VAP.
4. List any affected packages or components.
OpenShift
Red Hat Advanced Cluster Manager
Red Hat Advanced Cluster Security (in case of overlap on policies but not directly affected AFAIK)