False positive detected deprecation ? about kubepug HOT 4 CLOSED

Hi @yogeek and thanks for the issue :)

You're right, this is a false positive. This has been already mapped in #72 and it's in my backlog.

I'm finishing to re-structure the code so it will be easier to put each behavior in each input format, as this is a false positive when you're using a k8s cluster but not when you're using an input file :)

I'll keep this open just to make sure those are the same issues and I'm not letting anything pass, and expect to correct this by the weekend :)

Thank you!

from kubepug.

Hey @yogeek

About the last-applied, it's an annotation containing the marshalled JSON used to apply to kube-apiserver but AFAIK annotations are just metadata put by the object owner (like the user, the developer) or by the controller to represent something. It shall not be used to control the behavior of the object in the cluster, EXCEPT in cases like Ingress Controllers that still uses annotations in Ingress Objects as this was the best way to achieve this.

And this is why also CRD came to life and are turning the de-facto objects for non existing things in the Core of Kubernetes :)

So no, this annotation should not represent how the object is persisted in apiserver (and ETCD). Probably the api server mutates the object before persisting it in the etcd server, and I should think that also when you migrate from a version to other the apiserver might convert those objects if this is supported but I really need to test.

I've made a quick test here, creating a ClusterRoleBinding with the stable/final version (rbac.authorization.k8s.io/v1) and then getting the v1beta1 and it was returned in both listings, so my guess is that the API Server have a preferred GroupVersion (that I'm using in the code that will convert this here) but it still accepts if you want to get the older beta version.

About the tool, the approach is slight different: It lists all the possible APIs that Kubernetes might have using the swagger.json and with the description containing the "DEPRECATED" word and then tries to fetch each of them in the cluster. If the list is bigger then 1 (that happens as we have seen in this bug) it marks all the objects as deprecated.

The change of approach here is going to be: Gets all the APIs and their Preferred GroupVersion (like ClusterRoleBinding have rbac.authorization.k8s.io in v1 and v1beta1), checks if there's an object in the deprecated api group/version, if so checks the preferred group/version for that same resource and if the length is the same (meaning those are the same API Resources but in different groups), pass to the next as this might not be deprecated :)

from kubepug.

@yogeek I'm closing this in favor of #72 but please feel free to reach me or reopen if you think those are different issues :)

Thank you

from kubepug.

Hi @rikatz ! Just a quick question : after I opened this issue, I noticed that the resource apiVersion was indeed rbac.authorization.k8s.io/v1 but the "last-applied" configuration apiVersion was in beta... Does it mean the YAML that were applied to the cluster contained 'beta' but during the apply, kubernetes modified it to set the 'v1' apiVersion ? Is it possible ?
And do your tool look at the real apiVersion or at the 'last-applied' one ?

from kubepug.