Support Kyverno policies

[JimBugwadia]

Is your feature request related to a problem? Please describe.

Kyverno policies are not listed in ArtifactHub.

Describe the solution you'd like

List Kyverno policies in ArtifactHub.

Describe alternatives you've considered

Additional context

Kyverno sample policies are maintained in:

https://github.com/kyverno/policies

These policies then get rendered to:

https://kyverno.io/policies/

There also is a Helm chart for Kyverno policies that implement the pod security standards:

https://artifacthub.io/packages/helm/kyverno/kyverno-policies

[tegioz]

Hi @JimBugwadia 👋

Kyverno policies would be a nice addition to Artifact Hub, we'll take care of it soon 🙂

[tegioz]

We've just added experimental support for Kyverno policies @JimBugwadia 🙂

We've listed a sample policies repository, you can see it in action in staging. It'd be great if you can list the Kyverno policies repository on https://artifacthub.io when it's ready 😇 You can check the repositories guide as well as the annotations document for more information. I would recommend checking out how other projects are organizing the Artifact Hub metadata for inspiration:

• Keda: https://github.com/kedacore/external-scalers/tree/main/artifacthub
• Keptn: https://github.com/keptn-contrib/artifacthub
• Kubewarden: https://github.com/kubewarden/allowed-fsgroups-psp-policy
• Tinkerbell: https://github.com/tinkerbell/hub/tree/artifacthub-manifests/actions
• Gatekeeper: https://github.com/open-policy-agent/gatekeeper-library/tree/master/artifacthub

Don't hesitate pinging us with any question or if you find any issue 😉

[chipzoller]

Hi @tegioz and thanks for this. A couple of questions:

1. I see there is a artifacthub-repo.yml file required in which the key piece of information is the repositoryID. This looks to be project specific and even after looking at your fork (where staging is pointed), I'm not seeing what our repositoryID value would be.
2. Is there a way to get Artifact Hub to recursively pick up our policies, possibly by applying some file filter, without having to specify a artifacthub-pkg.yml file for each one? Kyverno has over 260+ policies which will make it the fourth-largest Kind on ArtifactHub, just behind Tekton tasks. If an artifacthub-pkg.yml file is mandatory for each one this is going to be a very long process.

[tegioz]

Hi @chipzoller 👋

1. You can get the repositoryID from the AH control panel once you register the repository. The artifacthub-repo.yml file is optional though, and only needed at the moment for some features like getting the verified publisher status or claiming the ownership of a repository.

2. Maybe you could automate this process. Gatekeeper is handling their policies this way, for example. They have a script called from their CI workflow to keep the AH metadata in sync automatically. You can store it in a different branch as well, like Tinkerbell does. For more inspiration please see the other links I shared above 🙂

An alternative would have been to, instead of using the generic tracker, add a specific tracker source for Kyverno policies. But we are trying to move away from that approach unless it's really needed for a number of reasons.

One of the them is that when using a custom tracker source, we still need to be able to collect AH specific metadata to power the features supported. In this case, this probably would have been done with annotations, which would have required polluting policies with data that isn't actually required for Kyverno to operate (and that still requires work with a large number of packages, with the risk of introducing errors).

Sometimes there are AH features that may not align well with the structure of the source repository as it is. AH for example supports package versioning, but I couldn't find how Kyverno policies are versioned at the moment. By using the metadata structure provided, Kyverno policies repositories publishers can opt-in for AH versioning if they'd like (please note that any org or user can now list their Kyverno policies repositories on AH).

We'd also like to keep AH as simple to maintain and extend as possible. At the moment we support 16 different repository kinds and it keeps growing! Having a source tracker for each kind usually means that when a new feature is added we need to prepare each kind for it, update the AH linter, the corresponding docs, etc. We also need to keep track of how each of the kinds evolves its directory layout and metadata formats over time. If the number of kinds keeps growing, that might not scale well. Sometimes there are already a lot of repositories of a given kind that depend on a specific structure required by the corresponding tooling, like Helm charts, and a custom source tracker may be justified. But if the kind allows for more flexibility then relying on the generic one may be the best option.

Hope this helps 🙂