Feature Request: Allow users to specify policies that also apply to kubewarden namespace

[sventenraa]

Is your feature request related to a problem?

Currently the kubewarden-controller adds an exclusion rule to all webhookconfigurations to ignore the namespace in which kubewarden itself is running.

We would like a feature toggle to be added to allow policies to bypass this anti-lockout mechanism so that some resources can be protected/mutated even in the kubewarden namespace.

The implementation would ideally introduce a feature toggle on the clusteradmissionpolicy resource that is evaluated for true false in

kubewarden-controller/internal/controller/policy_subreconciler_webhook.go

Line 193 in 3c5e2fd

func (r *policySubReconciler) namespaceSelector(policy policiesv1.Policy) *metav1.LabelSelector {

(with a default of apply the exclusion of kubewarden namespace).

Solution you'd like

So flow would be:

apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: loadbalancerdeny
spec:
  module: registry://<registry>v0.0.1
  settings: {}
  rules:
  - apiGroups:
    - ''
    apiVersions:
    - v1
    resources:
    - namespaces
    operations:
    - CREATE
    - UPDATE
  mutating: false
  defaultexclusion: true

If you don't want the webhook to have the deployed namespace for kubewarden excluded.
This setting would default to false if not specified and thereby allow current users to experience existing behaviour of kubewarden.

Alternatives you've considered

No response

Anything else?

No response

[viccuad]

Hi, thanks for opening this feature request!

This is a valid request, there may be cases where being able to run policies against the resources in the kubewarden namespace (usually, workload resources). Yet, if misconfigured, this may end with a non-functioning policy engine that drops all webhooks, breaking the cluster in a DoS attack.

May I ask what kind of usecases do you have in mind if this feature would be provided?

WRT implementation, there's 2 ways that come to mind:

1. Completely remove the controller code that checks for the Kubewarden namespace. Move this current feature into the helm-chart by appending Release.namespace in the value global.skipNamespaces. Users can then configure the Helm chart to skip the release namespace.
2. Put the deactivation of controller code that checks for the Kubewarden namespace under a flag. The default, not passing this new flag, would be the current behaviour. Allow to disable it in with a new value that passes the flag in the Helm chart.

[sventenraa]

May I ask what kind of usecases do you have in mind if this feature would be provided?

We have a lot of policies that are currently being excluded from some core namespaces in order to prevent a deadlock when worker nodes get wiped (cluster is put to standby).
Due to the validatingwebhookconfigurations (and some mutatingwebhookconfigurations) preventing pods from starting until the currently used admission controllers are available.

By excluding more namespaces we are currently able (by using alternatives to kubewarden) to work around this deadlock situation.
However, ideally policies like (2 examples):

• Disallow re-using the same hostname on a custom resource
• Prevent core namespaces from being modified unless the request came from a service account in list or specific users

Should be able to be applied to all resources (of that specific kind) in the cluster.
We are currently looking into migrating to kubewarden since it's approach of generating a custom webhook configuration per policy allows us the flexibility to apply cluster wide policies without either causing deadlocks or having to exclude more namespaces from other policies due to multiple resource types being handled by the same webhookconfiguration.

In my opinion an approach where the end users can specify to override excluding the kubewarden source namespace would allow for more flexibility for setting up certain resources that should also be checked / made to conform in the kubewarden namespace.

As you stated this would introduce the possibility that end-users could create a deadlock by requiring admission for kubewardens resources that prevent kubewarden from correctly starting. Therefore I view this as a "advanced" user solution with a explicit assumption the risk by going with this approach.

The alternatives to the solution for adding a clusteradmissionspolicy feature flag that would either execute the kubewarden deployed namespace exclusion or not would all achieve the same functionality.

It is however important to point out that this feature is requested for user generated webhookconfigurations (the core webhooks generated by kubewarden do not have to be included in this change).

Having this feature implemented via helm would make it possible to still achieve the kubewarden exclusion behaviour by adding the kubewarden-system namespace as an explicit exclusion for that specific policy.

While making it a feature flag for each clusteradmissionpolicy would invert the logic from default nothing will be excluded (helm approach) to default everything is still excluded unless you set a featureflag to true telling the controller to not include the kubewarden deployed namespace to it's exclusions.

The helm approach is for our situation better since we strife to an 'a policy should apply to all resources within cluster, unless' approach. Whereas my earlier suggested approach would be more in line with current behaviour (would be less of a big bang for existing users)