FairwindsOps/pluto

`kubectl.kubernetes.io/last-applied-configuration` annotation causes false positive on deprecated api report

chauncey-garrett opened this issue · 4 comments

What happened?

We have a CronJob that showed up in the pluto report.

For this resource, the kind has been updated to a current API but the kubectl.kubernetes.io/last-applied-configuration still shows the deprecated API.

apiVersion: batch/v1
kind: CronJob
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"batch/v1beta1","kind":"CronJob",...

Here you can see that batch/v1 is used but batch/v1beta1 still exists on the annotation. Pluto marks this as a resource in need of update.

I consider this to be a false positive.

Pluto report:

NAME                                           NAMESPACE               KIND                       VERSION                        REPLACEMENT               DEPRECATED   DEPRECATED IN   REMOVED   REMOVED IN   REPL AVAIL   REPL AVAIL IN  
my-cronjob                                     my-namespace            CronJob                    batch/v1beta1                  batch/v1                  true         v1.21.0         true      v1.25.0      true         v1.21.0 

What did you expect to happen?

I'd expect the pluto report to not include results from the kubectl.kubernetes.io/last-applied-configuration annotation since this would require a 2nd deployment to clear items from the report.

How can we reproduce this?

Add a deprecated api to the kubectl.kubernetes.io/last-applied-configuration annotation while using a current one on the resource.

Version

Version:5.16.3 Commit:02eccc41292c2b4380fa05f6406628fd1afe6cb9

Search

  • I did search for other open and closed issues before opening this.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Additional context

No response

Yes, unfortunately this is entirely possible due to the nature of the last-applied-configuration annotation. If this is an issue, I recommend either using Pluto with your Infra-as-Code, or only using the in-cluster helm detection.

We allude to some of the uncertainty of that annotation in the docs here but we could probably expand that to include this issue as well.

Would you be willing to add this to the documentation?

so what is the status now? Any coding task is needed?

@csimplestring No, there is no coding task needed as far as I can tell, just some better documentation.