fairwindsops/pluto

A cli tool to help discover deprecated apiVersions in Kubernetes

Find Kubernetes resources that have been deprecated

Pluto is a utility to help users find deprecated Kubernetes apiVersions in their code repositories and their helm releases.

Documentation

Check out the documentation at docs.fairwinds.com

Purpose

Kubernetes sometimes deprecates apiVersions. Most notably, a large number of deprecations happened in the 1.16 release. This is fine, and it's a fairly easy thing to deal with. However, it can be difficult to find all the places where you might have used a version that will be deprecated in your next upgrade.

You might think, "I'll just ask the api-server to tell me!", but this is fraught with danger. If you ask the api-server to give you deployments.v1.apps, and the deployment was deployed as deployments.v1beta1.extensions, the api-server will quite happily convert the api version and return a manifest with apps/v1. This is fairly well outlined in the discussion in this issue.

So, long story short, finding the places where you have deployed a deprecated apiVersion can be challenging. This is where pluto comes in. You can use pluto to check a couple different places where you might have placed a deprecated version:

• Infrastructure-as-Code repos: Pluto can check both static manifests and Helm charts for deprecated apiVersions
• Live Helm releases: Pluto can check both Helm 2 and Helm 3 releases running in your cluster for deprecated apiVersions

Kubernetes Deprecation Policy

You can read the full policy here

Long story short, apiVersions get deprecated, and then they eventually get removed entirely. Pluto differentiates between these two, and will tell you if a version is DEPRECATED or REMOVED

GitHub Action Usage

Want to use pluto within your GitHub workflows?

- name: Download Pluto
  uses: FairwindsOps/pluto/github-action@master

- name: Use pluto
  run: |
    pluto detect-files -d pkg/finder/testdata

Join the Fairwinds Open Source Community

The goal of the Fairwinds Community is to exchange ideas, influence the open source roadmap, and network with fellow Kubernetes users. Chat with us on Slack or join the user group to get involved!

Other Projects from Fairwinds

Enjoying Pluto? Check out some of our other projects:

• Polaris - Audit, enforce, and build policies for Kubernetes resources, including over 20 built-in checks for best practices
• Goldilocks - Right-size your Kubernetes Deployments by compare your memory and CPU settings against actual usage
• Nova - Check to see if any of your Helm charts have updates available
• rbac-manager - Simplify the management of RBAC in your Kubernetes clusters

Or check out the full list

Fairwinds Insights

If you're interested in running Pluto in multiple clusters, tracking the results over time, integrating with Slack, Datadog, and Jira, or unlocking other functionality, check out Fairwinds Insights, a platform for auditing and enforcing policy in Kubernetes clusters.

pluto's Issues

add testing to helm package

Automatic upgrade of files

[feature-request]

Add a flag to upgrade files that are on deprecated versions e.g. deployments.v1beta1.extensions -> deployments.v1.apps.

Detect deprecated/removed apiGroups in Role/ClusterRole rules

Are there any plans to add detection of deprecated/remove apiGroups in Role/ClusterRole rules?

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
# Detection: Need to add 'apps' because 'extensions' will be removed in v1.16
- apiGroups: ["extensions"] 
  resources: ["deployments"]
  verbs: ["get", "watch", "list"]

We are currently detecting these apiGroups by using conftest tool with custom policy but it would be great to have these detection in pluto.

Important Note

In the example above, 'extensions' apiGroup must not be removed until the cluster is actually upgraded to v1.16.

This is because Preferred Version of Deployment kind in v1.15 is still 'extensions'. For example, you add 'apps' apiGroup and remove 'extensions' from 'deployments' resource in the Role/ClusterRole. If you execute following command with updated Role/ClusterRole in v1.15, the access forbidden error will be raised.

# Forbidden error. 'deployment' means 'deployment.extensions'.
kubectl get deployment

# Avoid forbidden error by explicitly specifying apiGroup 'apps'.
kubectl get deployment.apps 

Therefore detection rule/message/information should be carefully considered.

• v1.16: Add 'apps' apiGroup
  • Current running version is v1.15. Removing 'extensions' apiGroup may cause problem mentioned above.
• v1.17: Remove 'extensions' apiGroup
  • Current running version is v1.16. 'extensions' apiGroups can be removed safely.

Revisit output when detect-helm is used

Thoughts:

• It would be useful if the chart name is a column in the output
• When looking at a few clusters using the detect-helm feature, I realized it becomes harder to identify things without the namespace in the output. Also since the same chart could be launched into different namespaces, having the namespace along with the chart name will reduce a couple investigation steps after running pluto.

Those couple things being said. I propose our output change to something like this only when detect-helm is used:

NAMESPACE\t CHART\t KIND\t VERSION\t DEPRECATED\t RESOURCE NAME

Open to thoughts on this. I could also see us implementing a -o wide output option for more fields. Perhaps having TEMPLATE with a value of the template file within the chart.

Consider publishing a github action

If we published an action, then people could easily run Pluto against their code.

Rename to Pluto

Document exit-code option for CI/CD

issue with Helm (v2) detection on my cluster

Hello,
we have a lot of (big, fat, awful) helm deployment and I wanted to check deprecation with pluto:

but it doesn't work as expexted (I assume):

$ helm ls
NAME                        	REVISION	UPDATED                 	STATUS  	CHART                             	APP VERSION	NAMESPACE
kube-eagle                  	1       	Wed Apr 15 06:44:59 2020	DEPLOYED	kube-eagle-1.1.5                  	1.1.0      	monitoring
onap                        	1       	Wed Apr 15 07:21:11 2020	DEPLOYED	onap-6.0.0                        	El Alto    	onap
onap-aaf                    	1       	Wed Apr 15 07:21:12 2020	DEPLOYED	aaf-6.0.0                         	           	onap
onap-aai                    	1       	Wed Apr 15 07:21:13 2020	DEPLOYED	aai-6.0.0                         	           	onap
onap-appc                   	1       	Wed Apr 15 07:21:21 2020	DEPLOYED	appc-6.0.0                        	           	onap
onap-cassandra              	1       	Wed Apr 15 07:21:26 2020	DEPLOYED	cassandra-6.0.0                   	           	onap
onap-cds                    	1       	Wed Apr 15 07:21:27 2020	DEPLOYED	cds-6.0.0                         	           	onap
onap-clamp                  	1       	Wed Apr 15 07:21:30 2020	DEPLOYED	clamp-6.0.0                       	           	onap
onap-cli                    	1       	Wed Apr 15 07:21:31 2020	DEPLOYED	cli-6.0.0                         	           	onap
onap-consul                 	1       	Wed Apr 15 07:21:31 2020	DEPLOYED	consul-6.0.0                      	           	onap
onap-contrib                	1       	Wed Apr 15 07:21:33 2020	DEPLOYED	contrib-6.0.0                     	           	onap
onap-dcaegen2               	1       	Wed Apr 15 07:21:35 2020	DEPLOYED	dcaegen2-6.0.0                    	           	onap
onap-dcaemod                	1       	Wed Apr 15 07:21:54 2020	DEPLOYED	dcaemod-6.0.0                     	           	onap
onap-dmaap                  	1       	Wed Apr 15 07:22:01 2020	FAILED  	dmaap-6.0.0                       	           	onap
onap-esr                    	1       	Wed Apr 15 07:37:11 2020	DEPLOYED	esr-6.0.0                         	           	onap
onap-log                    	1       	Wed Apr 15 07:37:13 2020	DEPLOYED	log-6.0.0                         	           	onap
onap-mariadb-galera         	1       	Wed Apr 15 07:37:14 2020	DEPLOYED	mariadb-galera-6.0.0              	           	onap
onap-modeling               	1       	Wed Apr 15 07:37:15 2020	DEPLOYED	modeling-6.0.0                    	           	onap
onap-msb                    	1       	Wed Apr 15 07:37:17 2020	DEPLOYED	msb-6.0.0                         	           	onap
onap-multicloud             	1       	Wed Apr 15 07:37:19 2020	DEPLOYED	multicloud-6.0.0                  	           	onap
onap-nbi                    	1       	Wed Apr 15 07:37:21 2020	DEPLOYED	nbi-6.0.0                         	           	onap
onap-oof                    	1       	Wed Apr 15 07:37:25 2020	DEPLOYED	oof-6.0.0                         	           	onap
onap-policy                 	1       	Wed Apr 15 07:37:34 2020	DEPLOYED	policy-6.0.0                      	           	onap
onap-pomba                  	1       	Wed Apr 15 07:37:40 2020	DEPLOYED	pomba-6.0.0                       	           	onap
onap-portal                 	1       	Wed Apr 15 07:37:44 2020	DEPLOYED	portal-6.0.0                      	           	onap
onap-robot                  	1       	Wed Apr 15 07:37:47 2020	DEPLOYED	robot-6.0.0                       	           	onap
onap-sdc                    	1       	Wed Apr 15 07:37:48 2020	DEPLOYED	sdc-6.0.0                         	           	onap
onap-sdnc                   	1       	Wed Apr 15 07:37:51 2020	DEPLOYED	sdnc-6.0.0                        	           	onap
onap-sniro-emulator         	1       	Wed Apr 15 07:48:31 2020	DEPLOYED	sniro-emulator-6.0.0              	           	onap
onap-so                     	1       	Wed Apr 15 07:48:31 2020	DEPLOYED	so-6.0.0                          	           	onap
onap-uui                    	1       	Wed Apr 15 07:50:13 2020	DEPLOYED	uui-6.0.0                         	           	onap
onap-vfc                    	1       	Wed Apr 15 07:50:14 2020	DEPLOYED	vfc-6.0.0                         	           	onap
onap-vid                    	1       	Wed Apr 15 07:50:19 2020	DEPLOYED	vid-6.0.0                         	           	onap
onap-vnfsdk                 	1       	Wed Apr 15 07:50:22 2020	DEPLOYED	vnfsdk-6.0.0                      	           	onap
prometheus-blackbox-exporter	1       	Wed Apr 15 06:44:51 2020	DEPLOYED	prometheus-blackbox-exporter-3.4.0	0.15.1     	monitoring
prometheus-operator         	1       	Wed Apr 15 06:43:30 2020	DEPLOYED	prometheus-operator-8.12.13       	0.37.0     	monitoring
weave-scope                 	1       	Wed Apr 15 06:43:09 2020	DEPLOYED	weave-scope-1.1.10                	1.12.0     	monitoring
$ pluto detect-helm -v8 --helm-version=2
I0415 15:21:48.554216   17322 loader.go:375] Config loaded from file:  /Users/sylvain/.kube/config
I0415 15:21:48.556031   17322 round_trippers.go:420] GET https://127.0.0.1:6443/api/v1/configmaps?labelSelector=OWNER%3DTILLER
I0415 15:21:48.556058   17322 round_trippers.go:427] Request Headers:
I0415 15:21:48.556067   17322 round_trippers.go:431]     Accept: application/json, */*
I0415 15:21:48.556074   17322 round_trippers.go:431]     User-Agent: pluto/v0.0.0 (darwin/amd64) kubernetes/$Format
I0415 15:21:48.729969   17322 round_trippers.go:446] Response Status: 200 OK in 173 milliseconds
I0415 15:21:48.729998   17322 round_trippers.go:449] Response Headers:
I0415 15:21:48.730006   17322 round_trippers.go:452]     Content-Type: application/json
I0415 15:21:48.730013   17322 round_trippers.go:452]     Date: Wed, 15 Apr 2020 13:21:48 GMT
I0415 15:21:49.231527   17322 request.go:1017] Response Body: {"kind":"ConfigMapList","apiVersion":"v1","metadata":{"selfLink":"/api/v1/configmaps","resourceVersion":"189177"},"items":[{"metadata":{"name":"kube-eagle.v1","namespace":"kube-system","selfLink":"/api/v1/namespaces/kube-system/configmaps/kube-eagle.v1","uid":"e5262e4b-ef59-420b-809e-595dfc7fd5fa","resourceVersion":"7664","creationTimestamp":"2020-04-15T04:44:59Z","labels":{"MODIFIED_AT":"1586925899","NAME":"kube-eagle","OWNER":"TILLER","STATUS":"DEPLOYED","VERSION":"1"}},"data":{"release":"H4sIAAAAAAAC/+w8d1gU1/bYoo4kMaiILVwXECHsAioGVsUCKCjSQQUjzu7e3R2YnVlmZqkSsMSIIpZIgr3FrjGaoGJvsUfBgooKJsYQK3ZUhP19M7MdMJKXvPe97/38g2925tzT77nnnnuuCJKokUAhRBU4tLnfAtnXok0zwa4WDg4OYJThA3BwcEAQmKomKQaEhfrHhwwdHTDIsTc7VMrgQAEZoCZlNBAKCVQFaTUqhUBFEhhDUhihAEIcCFC1epCRlBsFcYjS0OSVAAhJkECThBpllIMEGSKMgSo6zuMzkQoyqAxlUBGLPFPggiBQqiSBIIoEDKQZwCghkGsIKYORBIpjTJoboCGjUQMU6DlkORfKSSoFpWSAJEAaqaEATkpRHKhQqRIjoAhEKSH3AUhRAiRjNMZjlkCcTAHREcG0QEc3hvumZBi12N3ds8+nIg+Rh8hT7O3h7eGuggyFSWnAkECqhNJEDgWrORrKgO7ju+BRQhRnlCwaFZoIAa2hICcM4A2C0YDSEASr [truncated 5624181 chars]
I0415 15:21:49.492648   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.493304   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.500651   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.530575   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.543033   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.545200   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.548839   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.554656   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.555173   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.560202   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.566084   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.580253   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.586464   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.587965   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.592394   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.593796   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.596183   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.600184   17322 versions.go:129] not json: invalid character '-' in numeric literal
I0415 15:21:49.602625   17322 versions.go:135] not yaml: yaml: unmarshal errors:
  line 969: mapping key "metadata" already defined at line 966
Error running helm-detect: no matches for stub, error: yaml: unmarshal errors:
  line 969: mapping key "metadata" already defined at line 966

fyi I'm "out of cluster" with ssh proxy in between if

In cluster resources?

Hi!

Is there a way to check for resources inside the cluster?

For example, we run a multi-tenant cluster and some teams may choose to apply their manifests directly to the cluster and we do not really have any visibility on those files.

Does pluto support detecting resources that are already inside the cluster, outside of helm?

Thanks!

Don't show header if no results are to be printed

If you have non-deprecated versions found, and you don't specify --show-non-deprecated, then you might get:

└─ helm template . | pluto detect -
KIND   VERSION   DEPRECATED   RESOURCE NAME

This is weird and confusing. We should detect this and print a "no deprecated versions found" message

Create a custom-columns output option

Allow only displaying certain output columns

From #91

Add semantic versioning tags to Docker container

Quay.io repo tags not currently in vx.x.x format.

Success message is misleading and/or --show-all is not working

Consider this file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: testapp
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: testapp

It is "up to date" version-wise.

But running pluto on that dir reports "No api-versioned files found in specified directory.".

❯ pluto detect-files -d .
No api-versioned files found in specified directory.

That's not really true. It did find it (can be seen in verbose logs), it is just that the file is compliant. This can lead you to think that your directory path is wrong.

Even running with --show-all reports nothing.

❯ pluto detect-files -d .  --show-all
No api-versioned files found in specified directory.

It is there though. If I change it to an old api version it is found.

❯ pluto detect-files -d .           
NAME      KIND         VERSION        REPLACEMENT   REMOVED   DEPRECATED  
testapp   Deployment   apps/v1beta1   apps/v1       true      true  

The success message should probably indicate files were found and parsed.

Possibly a separate issue, is --show-all working as expected?

Only show latest DEPLOYED release when using helm

There is a bug in helm (2 for sure, unclear when using version 3) that can allow a release to have multiple revisions marked as DEPLOYED. Because of this all of those revisions get listed in pluto output. We should only care about the most recent one.

Bonus: should we also alert the user they are hitting this bug? It is not a feature of helm to have more than one DEPLOYED release at at ime.

Support targeting a kubernetes version

By default right now, we target Kubernetes version 1.16 since that's what we are worried about. However to make this future-proof, we should support multiple.

One option that was discussed was to move to a DeprecatedIn string, instead of a Deprecated boolean. That way we can easily compare and decide if we should display it.

Add a command to list the deprecations that pluto knows about

Something like pluto list-known or something like that which will output a table or JSON or yaml of the deprecation list.

detect-helm and multiple uses of the same chart

When multiple releases are from the same chart, I think we should only show one instance of that output.

for example, if helm ls shows this:

NAME                                        	REVISION	UPDATED                 	STATUS  	CHART                              	APP VERSION	NAMESPACE
app-develop                                 	5       	Tue Apr 21 04:13:25 2020	DEPLOYED	app-1                           	1.0        	develop
app-qa                                       	5        	Tue Apr 21 04:13:25 2020	DEPLOYED	app-1                           	1.0        	qa

We should only output a single line for any deprecations found in that chart. This may be easier if we end up pulling in chart name data with #31

go get throws import errors

└─ go get github.com/fairwindsops/pluto
unrecognized import path "helm.sh/helm/pkg/storage": reading https://helm.sh/helm/pkg/storage?go-get=1: 404 Not Found
unrecognized import path "helm.sh/helm/pkg/storage/driver": reading https://helm.sh/helm/pkg/storage/driver?go-get=1: 404 Not Found
unrecognized import path "helm.sh/helm/v3/pkg/storage": reading https://helm.sh/helm/v3/pkg/storage?go-get=1: 404 Not Found
unrecognized import path "helm.sh/helm/v3/pkg/storage/driver": reading https://helm.sh/helm/v3/pkg/storage/driver?go-get=1: 404 Not Found

Add full path to file detection output

Have the option to output the full filepath for use in automation

Change —show-non-deprecated

Make it —show-all with a -A shorthand

detect-helm reports no error if API is unreachable

We should definitely get an error for this instead:

$ kubectl get no
The connection to the server 127.0.0.1:32768 was refused - did you specify the right host or port?                                                                                                                                                                       
$ pluto detect-helm --helm-version 2
There were no apiVersions found that match our records.
$ pluto detect-helm --helm-version 3
There were no apiVersions found that match our records.

More filtering options

Hi, great tool! I would love to have more filtering options. Specifically for my use case:

1. Filter by provider (e.g., only show Kubernetes deprecations, not Istio or Cert Manager)
2. Filter by removed vs. deprecated (e.g., I only want to see which APIs are going to be removed in Kubernetes 1.16). I tried --ignore-deprecations but that seemed to only affect the exit code

As a workaround, I used jq to filter the JSON, but then I have to re-format the output.

Thanks again for the great tool!

Consider adding popular CRD deprecations

cert-manager comes to mind specifically

This could entail adding a field to the Version struct, such as DeprecationType or APISource

Support helm templates in static files check

Helm templates do not unmarshal to yaml. Options are:

• Run a helm-template on the chart and scan that
• Strip all templating strings and attempt an unmarshal
• Something else I haven't thought of

Set non-zero exit code if there are deprecated resources

Would be great to fail (e.g. in CI/CD) if there are deprecated resources.

Could be done only in the presence of a flag (e.g. --set-exit-code)

Catch helm no deployed releases and log it without blocking

Thanks for the great product. Regretfully we're getting this error

time pluto detect-helm --helm-version=2 -v 8 -n bc-production
I0603 17:29:04.589249  150123 loader.go:375] Config loaded from file:  ~/.kube/config
I0603 17:29:04.591774  150123 round_trippers.go:420] GET https://<11.22.33.44>/api/v1/configmaps?labelSelector=OWNER%3DTILLER
I0603 17:29:04.591845  150123 round_trippers.go:427] Request Headers:
I0603 17:29:04.591864  150123 round_trippers.go:431]     Accept: application/json, */*
I0603 17:29:04.591878  150123 round_trippers.go:431]     User-Agent: pluto/v0.0.0 (linux/amd64) kubernetes/$Format
I0603 17:29:05.679000  150123 round_trippers.go:446] Response Status: 200 OK in 1087 milliseconds
I0603 17:29:05.679061  150123 round_trippers.go:449] Response Headers:
I0603 17:29:05.679094  150123 round_trippers.go:452]     Audit-Id: ae0c62cc-685e-4408-9964-ebd846237393
I0603 17:29:05.679119  150123 round_trippers.go:452]     Content-Type: application/json
I0603 17:29:05.679140  150123 round_trippers.go:452]     Date: Wed, 03 Jun 2020 15:29:05 GMT
I0603 17:30:39.395310  150123 request.go:918] Stream error http2.StreamError{StreamID:0x1, Code:0x2, Cause:error(nil)} when reading response body, may be caused by closed connection.
Error running helm-detect: stream error when reading response body, may be caused by closed connection. Please retry. Original error: stream error: stream ID 1; INTERNAL_ERROR

real	1m34.845s
user	0m4.633s
sys	0m7.229s

Tried for root of repo's (many projects), in certain repo root folder, in the ci/templates folder: the timeout differs, but they all fail on the same line request.go:918

Any solution? Other things we can try?

Add "removed in" column and adjust "deprecated in"

Currently our output has DEPRECATED/DEPRECATED IN when in reality it should be REMOVED/REMOVED IN.

We can still have a "deprecated in" column but it should truly be the deprecated kube version.

Question: Scope of API Deprecations

I just had a quick question about the scope of the tool. When I run this against my cluster, I get a report of deprecated API versions. However, the tool doesn't tell me in which version they were deprecated. Our clusters are on 1.12 and upgrading to 1.13 so it may not make sense to change all the resources reported by the tool.

Thank you so much for creating this tool. This will be immensely helpful as we upgrade some of our older clusters.

Consider checking things other than apiVersion

In particular this is in light of the ingress class annotation change in Kube 1.18

Allow filtering non-deprecated versions from yaml and json output

Currently, the show-all flag doesn't affect the yaml or json output. This should probably be the case.

Detect deprecated APIs in running clusters

Would be possible to add the approach described in https://github.com/doitintl/kube-no-trouble where the tool scans the resources in an existing cluster? @stepanstipl would you be keen to merge efforts?

Support helm 2

This will be tough because the data stored in the configmap is a long string and I can't figure out a logical separator between the different types of data stored there.

Include namespace in `detect` and `detect-files` output

IF a namespace is included in a manifest file, include that namespace along with the object name, as is done for pluto detect-helm output E.G. namespace/myapp.

Currently the object name is shown, with no namespace.

IF there is no namespace available in an objects metadata, potentially:

• Show only the object name, which is what happens in all cases now.
• Show unknown/ or similar to denote the namespace is unknown.
• Provide a flag to specify what should be shown if the namespace is unknown.

Add deprecations for 1.18.0

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md#deprecation

the following deprecated APIs can no longer be served:

• All resources under apps/v1beta1 and apps/v1beta2 - use apps/v1 instead
• daemonsets, deployments, replicasets resources under extensions/v1beta1 - use apps/v1 instead
• networkpolicies resources under extensions/v1beta1 - use networking.k8s.io/v1 instead
• podsecuritypolicies resources under extensions/v1beta1 - use policy/v1beta1 instead

Some of these we have already, but we should double check

Brew release for quick macos adoption.

Hello Feature request,

Would like to have a brew release so we MacOS user can quickly install/upgrade the tool.

Thanks!

Yaml and JSON only output version deprecated, not a bool

It will be much easier to consume the data if the semver comparison is already make.
Fixed by #59

Issues detecting on Ingress

Trying to detect on an ingress object:

cat << EOF | pluto detect - -v=10
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
EOF

And I see the following error and response:

I0501 10:38:38.954095 1267123 versions.go:98] invalid json: invalid character 'a' looking for beginning of value
There were no apiVersions found that match our records.
I0501 10:38:38.954169 1267123 root.go:209] retCode: 0

However works fine on a Deployment:

cat << EOF | pluto detect -      
apiVersion: apps/v1beta1             
kind: Deployment
EOF      

NAME   KIND         VERSION        REPLACEMENT   REMOVED   DEPRECATED  
       Deployment   apps/v1beta1   apps/v1       true      true 

Is this expected? am I holding it wrong? or is it a bug?

Support checking the kubectl.kubernetes.io/last-applied-configuration annotation

Some k8s manifests are applied by the cloud provider and will be missed by detect-files and detect-helm. A good example is how EKS handles CoreDNS and kubeproxy; they seem to be applied via kubectl apply. It would be awesome if pluto could check for this use case.

auto generate deprecations list

We should be able to generate the deprecations list automagically from the kubernetes swagger.json.

It has a fairly consistent pattern for deprecating the apiVersions in the description of the api.

https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json

To preview this - cat swagger.json | jq '.definitions[].description' | grep -i deprecate

We could probably do a very nice go generate command with a lot of matching (possibly fuzzy)

We will also have to look at this file from multiple versions of Kube (possibly all of them)

Re-do helm3 functional tests with secret-only

Let's re-write the helm3 functional tests to use a secret instead
of actually helm-applying the manifests. This should, in theory, make
the e2e/functional tests kubernetes-version agnostic, since we won't
actually be applying anything to the cluster.

Do functional testing with Kind

Add human-readable list output

Currently we only have JSON. Allow for yaml and human-readable like
our other outptus

Add a flag to only scan for certain components

Fom #91

Create a --components flag that takes a string slice and limits the providers (k8s, cert-manager, istio) that are scanned

Add a `replacement api` field to the output

We could add a field to the deprecations list that outputs the replacement api in order to assist even further.

could make #34 easier if we decide to do that.

Add a flag to --only-show-removed

From #91

Add a flag to --only-show-removed apiVersions. This may or may not affect error codes.

Error message shows wrong flag

└─ ./pluto detect-helm --helm-version 2
APIVersions were found, but none were deprecated. Try --show-non-deprecated.

Add deprecations for v1.17.0

• PriorityClass scheduling.k8s.io/v1beta1 [changelog] (https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.14.md#other-notable-changes-11) Added in #55
• All resources within the rbac.authorization.k8s.io/v1alpha1 and rbac.authorization.k8s.io/v1beta1 API groups are deprecated in favor of rbac.authorization.k8s.io/v1, and will no longer be served in v1.20. changelog
• The CSINodeInfo feature gate is deprecated and will be removed in a future release. The storage.k8s.io/v1beta1 CSINode object is deprecated and will be removed in a future release. (#83474, @msau42)changelog

Docker image unusable in GitLab

Hi,

GitLab CI/CD requires images to have a shell to be usable. Unfortunately, using scratch as the final base image does not provide any shell, and results in an error.

Any reasons for not using alpine as a base for the final image?

Idea: Allow targeting a single namespace for helm3 checks

It occurs to me that this might be nice for two reasons:

1. Developers in large clusters might only be responsible for a single namespace and want only info on that.
2. Someone using the tool might only have access to helm secrets in a single namespace, and want to target that namespace only

Pluto silently errors parsing valid yaml and returns success

We are seeing the following on Linux. It appears that pluto is failing to parse simple valid yaml, and is then reporting success.

1. Have a small yaml file:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: testapp

2. Run pluto detect-files -d .
3. See that exit code is 0

❯ pluto version
Version:3.1.2 Commit:20f146def8303190c923c5ec592a135b46da1c1a

Running with no logs it seems to claim no files exist, and there were no errors

❯ pluto detect-files -d .      
No api-versioned files found in specified directory.

❯ echo $?
0

Running with logs, we see the errors, and still a zero exit code

❯ pluto detect-files -d . -v 10
I0703 10:24:39.456542    3213 root.go:114] no additional versions needed
I0703 10:24:39.457064    3213 finder.go:95] processing file: test.yml
I0703 10:24:39.457173    3213 versions.go:114] 
apiVersion: v1
kind: ServiceAccount
metadata:
  name: testapp
I0703 10:24:39.457208    3213 versions.go:117] invalid json: invalid character 'a' looking for beginning of value
No api-versioned files found in specified directory.

❯ echo $?
0

I think there are two problems here.

1. pluto is trying to parse yaml files as JSON. The file can end .yaml or .yml, the error is the same.
2. pluto errors, but neither logs this by default, nor reports it as an exit code.

I can sort of see why the latter came about if you have non-k8s files in a dir structure. But for us the problem is that in our CI pluto started "doing nothing" but we never knew.

Can we have "strict mode" (by default!) that errors if it can't understand everything in a folder?

I may be missing a key bit of config here, (but that would hit the POLS)...