namespaced Helm resources using removed api-version show up with no namespace

[jrhunger]

#373 had a side effect

Example (on a cluster running v1.24.3):

8:08PM WRN failed to discover supported resources for networking.k8s.io/v1beta1: the server could not find the requested resource
...
>>> Deprecated APIs removed in 1.22 <<<
------------------------------------------------------------------------------------------
KIND                 NAMESPACE             NAME                             API_VERSION                         REPLACE_WITH (SINCE)
Ingress              <undefined>           elasticsearch-master             networking.k8s.io/v1beta1           networking.k8s.io/v1 (1.19.0)

I included the warning message because I see that in the code, and that if clause is returning false from isResourceNamespaced:
https://github.com/doitintl/kube-no-trouble/pull/373/files#diff-52cf05b270ce23924abdc3d3cd78665270611b25468cf728249f4bdb33eec0dcR42

I'm wondering if there is a way to check the replacement api version for the resource when the found one does not exist? (if the found one is removed, then the replacement one surely exists).

[stepanstipl]

Hi @jrhunger, this is an interesting edge case, thanks for reporting 👍. It makes sense we can't determine if a resource is namespaced if running on a cluster that doesn't know this resource (or given version) anymore.

Currently, the isResourceNamespaced is happening in the collector, so we know nothing about the deprecation/replacement at that stage. The other problem with the proposed solution is that not all resources we check here have replacements/are deprecated. It can simply be a non-deprecated custom resource, just currently unknown to the cluster.

I'm unsure at the moment if there's much we can do or, rather, a generic enough solution to improve the situation (I would like to avoid implementing several workarounds just covering a very small subset of the edge cases), but it's a good find. I'll keep it open for now to

[stepanstipl]

Further thought on this - maybe we can try to match if the same kind exists in the same group, but a different version. This wouldn't be 100% - still, there's not much we can do about a completely unknown resource - but it would help in the reported scenario.

I.e. we didn't find Ingress in networking.k8s.io/v1beta1, so the algorithm would try to continue to match Ingress in any version within the networking.k8s.io group, and match networking.k8s.io/v1.

[jrhunger]

In my cluster i have Ingress from both networking.k8s.io/v1beta1 and also extensions/v1beta1. The latter would not get picked up by this. Since there are only a small number of kinds that are deprecated per the Deprecated API Migration Guide and i think those are being manually added to the rego rules in this project, i wonder if it would be possible to also maintain a small static map or other data structure that could be consulted to determine if each (deprecated) kind is namespaced?

[stepanstipl]

Yep, this would be an option. I'm somewhat hesitant to add more static info that needs to be maintained, but it would solve the issue, and it's true there're not that many resources.

[github-actions]

This issue has not seen any activity in last 60 days, and has been marked as stale.

[github-actions]

This issue was closed because it has been stalled for 90 days with no activity.

[dohnto-s1]

This bug makes kubent really hard to use for me.

[evandeaubl]

Since these resources are related to Helm installs, and a Helm install is associated with a particular namespace, would it be reasonable as a fallback to assign the namespace of the Helm install where the resource was created from? At least that would give the user the namespace to look in for the offending Helm install.