Add support for annotations from Backstage Kubernetes plugin.

[Jonas-Beck]

This plugin already follows the Kubernetes plugin for Backstage since it requires a dependsOn relation with kubernetes-cluster. We should update the Kyverno annotations required so that if users have the Kubernetes plugin enabled for their service, the Kyverno plugin should also be set up and ready to use.

This means that backstage.io/kubernetes-namespace: should be able to be used instead of kyverno.io/namespaces, and if both are defined, the Kyverno one should be used.

We could also consider making the kinds and namespaces optional, meaning if none are provided, it will look at all namespaces for all Kubernetes kinds.

Currently the kyverno.io/resource-name is used to figure out what policies to show for a given service, using the value to search for policies that match this. Currently the resource filter for the policy reporter expects the exact resource name, making it hard to use when we would like to view policies for potentially any kind related to a service, including pods where the name would constantly change.

It would be great if we could use a label selector similar to how the Backstage kubernetes plugin handles showing resources related to a service.

This issue has three parts:

• Update the plugin to also support using Kubernetes plugin namespace annotation.
• Update the plugin to make namespace and kinds optional.
• Update the plugin to support backstage.io/kubernetes-id and backstage.io/kubernetes-label-selector instead of kyverno.io/resource-name. This would require the policy reporter API to support label selector [Core] New Filter: LabelSelector policy-reporter#223.

[andrewthauer]

@Jonas-Beck

I'm currently helping make a single pane of glass in Backstage for policies across clusters using this plugin. The goal is to see all policies (especially failed ones) in one spot for review across all resources & clusters within Backstage. Not specifically for a single catalog entity / namespace.

With some minor modifications to the code I've been able to do this, which is similar'ish to what you are proposing by making the annotations optional. I'd be happy to contribute this code back, but we should flush out the design first.

First, let me describe our current setup to accomplish this

1. We create an entity that looks like this:

   apiVersion: backstage.io/v1alpha1
   kind: Component
     metadata:
       name: policy-reporter
     annotations:
       # --- no kyverno annotations ---
       # kyverno.io/namespace: workflows
       # kyverno.io/kind: Deployment,Pod
       # kyverno.io/resource-name: workflows
   spec:
     dependsOn:
       - resource:default/cluster-a
       - resource:default/clluster-b

2. Remove the required annotations here https://github.com/kyverno/backstage-policy-reporter-plugin/blob/main/plugins/policy-reporter/src/utils/annotations.ts#L9-L11

3. Update these lines to have the annotations fallback to undefined instead of being required and throwing an error when not set.

This seems to work since the policy-reporter-backend already ignores undefined filters and the underlying policy-reporter API /namespaced-resources/results endpoint can filter and paginate these. This works great for an MVP and exactly want we want. That said, there are some rough edges and possible areas for improvement from a UX/DX perspective:

• The table search is client side only for the currently fetched page
• It's not possible to sort or filter server side
• This isn't a big one, but ability to search across clusters/environments
• It requires the usage of a somewhat dummy entity for this to work and no formal annotation indicator when viewing all

What I'm asking for / suggesting is probably a subset of what you are describing in the issue. Some of the UX things I suggested above are not a hard requirement for our initial usage, but viewing all policies for a cluster/environment are.

Again, I'm happy to push something upstream to support this initial case and we can discuss follow ups for the other items. Couple things come to mind to get us to an MVP state for our use case:

• Would you be open to making the annotations optional as I've done above. The only major downside I see is not having an easy way to identity entities that use them as optional. So it might require a new annotation to indicate kyverno-policy-reporter should be enabled.
• Maybe it would make sense to have a non entity bound component separate for viewing policies across the cluster?

[Jonas-Beck]

Hi @andrewthauer

Would you be open to making the annotations optional as I've done above. The only major downside I see is not having an easy way to identity entities that use them as optional. So it might require a new annotation to indicate kyverno-policy-reporter should be enabled.

I definitely think that making the annotations optional as you suggest is the correct solution. If you already have a local patch that would be awesome and we can just get it merged. The only issue with the current implementation is that it would need some way to identify the policies it should display at least for an EntityComponent. This would be the current resource-name annotation.

Maybe it would make sense to have a non entity bound component separate for viewing policies across the cluster?

Definitely sounds like your use case would best fit a new component similar to (#29) that would show global overview of policies.

With a global component it would also make sense to make use of the other policy-reporter endpoints to e.g. allow for selecting namespaces / kinds / sources with a dropdown.

This would also then not need to worry about the current required annotations since they would not be relevant for this. This component could potentially use annotations defined on groups if there was a need to e.g. limit the namespaces, environments or sources.

The table search is client side only for the currently fetched page

This would not be an issue with a more global component. Currently the search is used to figure out what policies to display for a certain entity due to not being able to fetch policies with a label selector.

Some follow up questions:

• Are you currently using the Backstage kubernetes plugin? If so would it for you make more sense to remove the resource-name annotations and then use the Kubernetes annotations to fetch the resources related to the service with the kubernetes api and show policies for those? This would mean that the client side table search would work for all policies and not only the fetched ones. This might not be that relevant for your global overview use case but would love the feedback.

• Would you need to be able to filter what policy sources to display for a global component e.g. Kyverno, Trivy, Falco?

• How would an ideal global overview component look for you?

[andrewthauer]

Are you currently using the Backstage kubernetes plugin?

Yes, we use the kubernetes-backend along with the catalogRelation service locator as well. That said we are more interesting in auditing by ops team atm. However, we did also look at https://github.com/TeraSky-OSS/backstage-plugins/tree/main/plugins/kyverno-policy-reports which used the k8s backend and the policyreports CRDs. This actually would have been less overall setup because we could have avoided creating exposing ingress across clusters and relying on the K8s API multi-cluster already setup in Backstage. That said, that plugin was not optimized to work across entities/namespaces so it didn't work out. However, after looking at the policy-reporter API it might provide some more flexibility for querying no?

Would you need to be able to filter what policy sources to display for a global component e.g. Kyverno, Trivy, Falco?

Only kyverno atm

How would an ideal global overview component look for you?

I think what you have started makes a lot of sense. After we use it a bit, I could probably give you a better answer. That said, I'm not entirely sure we need 3 different tables for the status. I suspect a filter for the results and a single table might be a litter better usage of space.