feat: Add Rancher Helm chart folder

[viccuad]

Description

Relates to https://github.com/kubewarden/rfc/pull/12

The policy resource template is rendered completely from whatever Helm values are passed. This is done by consuming everything in values.yaml, and of course accepts --set to overwrite, expand, or remove things that end in the template.

Test

To create an AdmissionPolicy instead of the default ClusterAdmissionPolicy: helm template . --set kind="AdmissionPolicy"

To set the policy as non-mutating: helm template . --set kind="AdmissionPolicy" --set mutating="false"

And so on.

Additional Information

Tradeoff

See RFC 10.

[flavio]

Does all of that have to live inside of the root of the repository? Can we put that under a dedicated directory instead (like rancher-helm-chart or something similar)?

[viccuad]

Yeah, simpler, no need for readme and so. Repushed the branch that way.

[flavio]

Yeah, simpler, no need for readme and so. Repushed the branch that way.

Thanks, I think this reduces the clutter and also makes it easy to find all the files that have to be touched in order to update the rancher chart

[flavio]

I spent more time looking into this PR, I was thinking about the conversation we had about adding all these information into the metadata.yml and then have a scaffold tool that generates these files. While doing that I came to some realizations.

Chart.yml file

• 99% of this file is not going to change over the time
• Parts that are going to change over the time:
  • appVersion key, this doesn't existing inside of this PR, I think it should be added. This must stay in sync with the version number of the policy
  • version: this is going to be a different version number compared to the one of the policy. Meaning, it wouldn't make much sense to have that included into the metadata.yml file

questions.yaml file

• The contents should not change over the time that often
• I think there should be a question about the policy deployment mode: protect/monitor
• We should add a question about the type of Kubewarden Policy CR that should be created: cluster-wide or namespaced? Note well, not all the policies might have this question. Policies inspecting cluster-wide resources (like Namespace) would not ask this question at all
• When the policy is deployed inside of a Namespace, the UI should ask for the name of the Namespace to be used. Is that possible?

policy.yaml and values.yaml file

I think the current contents of the values.yaml file should be moved into the policy.yaml file. The policy.yaml file should be a templated policy definition.

Things that should be templated are:

• The type of the resource to be created: ClusterAdmissionPolicy or AdmissionPolicy. This is based on the answer provided by the user
• The module url: keep in mind the policy could be mirrored somewhere else. We should provide the GHCR url as the default one, but allow the user to override that. I also have no idea about how the airgap tool of rancher handles that kind of stuff
• mutating: non-mutating policies will have this value hard coded, not templated. Mutating policies will have that value templated, it will depend on the answer provided by the user
• settings: this should be composed using the answers provided by the user

Summary

I wonder if it makes sense to have all this information stored into metadata.yml file. Is it going to be worth the effort given how few parts of the file need to be changed across releases?

Also, is it possible to have a really generic scaffold that covers all the policies? What about the exceptions, how are we going to handle them... These are questions for the RFC probably

[viccuad]

Superseded by https://github.com/kubewarden/helm-charts/pull/130/files.