zegl/kube-score

Kubernetes object analysis with recommendations for improved reliability and security. kube-score actively prevents downtime and bugs in your Kubernetes YAML and Charts. Static code analysis for Kubernetes.

kube-score

---

kube-score is a tool that performs static code analysis of your Kubernetes object definitions.

The output is a list of recommendations of what you can improve to make your application more secure and resilient.

You can test kube-score out in the browser with the online demo (source).

Installation

kube-score is easy to install, and is available from the following sources:

Distribution	Command / Link
Pre-built binaries for macOS, Linux, and Windows	GitHub releases
Docker	docker pull zegl/kube-score (Docker Hub)
Homebrew (macOS and Linux)	brew install kube-score
Krew (macOS and Linux)	kubectl krew install score

Sponsors

Your company here?

Checks

For a full list of checks, see README_CHECKS.md.

• Container limits (should be set)
• Pod is targeted by a NetworkPolicy, both egress and ingress rules are recommended
• Deployments and StatefulSets should have a PodDisruptionPolicy
• Deployments and StatefulSets should have host PodAntiAffinity configured
• Container probes, a readiness should be configured, and should not be identical to the liveness probe. Read more in README_PROBES.md.
• Container securityContext, run as high number user/group, do not run as root or with privileged root fs. Read more in README_SECURITYCONTEXT.md.
• Stable APIs, use a stable API if available (supported: Deployments, StatefulSets, DaemonSet)

Example output

Usage in CI

kube-score can run in your CI/CD environment and will exit with exit code 1 if a critical error has been found. The trigger level can be changed to warning with the --exit-one-on-warning argument.

The input to kube-score should be all applications that you deploy to the same namespace for the best result.

Example with Helm

helm template my-app | kube-score score -

Example with Kustomize

kustomize build . | kube-score score -

Example with static YAMLs

kube-score score my-app/*.yaml

kube-score score my-app/deployment.yaml my-app/service.yaml

Example with an existing cluster

kubectl api-resources --verbs=list --namespaced -o name \
  | xargs -n1 -I{} bash -c "kubectl get {} --all-namespaces -oyaml && echo ---" \
  | kube-score score -

Example with Docker

docker run -v $(pwd):/project zegl/kube-score:latest score my-app/*.yaml

Configuration

Usage of kube-score:
kube-score [action] --flags

Actions:
	score	Checks all files in the input, and gives them a score and recommendations
	list	Prints a CSV list of all available score checks
	version	Print the version of kube-score
	help	Print this message

Flags for score:
      --disable-ignore-checks-annotations   Set to true to disable the effect of the 'kube-score/ignore' annotations
      --disable-optional-checks-annotations Set to true to disable the effect of the 'kube-score/enable' annotations
      --enable-optional-test strings        Enable an optional test, can be set multiple times
      --exit-one-on-warning                 Exit with code 1 in case of warnings
      --help                                Print help
      --ignore-container-cpu-limit          Disables the requirement of setting a container CPU limit
      --ignore-container-memory-limit       Disables the requirement of setting a container memory limit
      --ignore-test strings                 Disable a test, can be set multiple times
      --kubernetes-version string           Setting the kubernetes-version will affect the checks ran against the manifests. Set this to the version of Kubernetes that you're using in production for the best results. (default "v1.18")
  -o, --output-format string                Set to 'human', 'json', 'ci' or 'sarif'. If set to ci, kube-score will output the program in a format that is easier to parse by other programs. Sarif output allows for easier integration with CI platforms. (default "human")
      --output-version string               Changes the version of the --output-format. The 'json' format has version 'v2' (default) and 'v1' (deprecated, will be removed in v1.7.0). The 'human' and 'ci' formats has only version 'v1' (default). If not explicitly set, the default version for that particular output format will be used.
  -v, --verbose count                       Enable verbose output, can be set multiple times for increased verbosity.

Ignoring a test

Tests can be ignored in the whole run of the program, with the --ignore-test flag.

A test can also be ignored on a per-object basis, by adding the annotation kube-score/ignore to the object. The value should be a comma-separated string of the test IDs.

Example:

Testing this object will temporarily disable the service-type test, which warns against using services of type NodePort.

apiVersion: v1
kind: Service
metadata:
  name: node-port-service-with-ignore
  namespace: foospace
  annotations:
    kube-score/ignore: service-type
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: NodePort

Enabling an optional test

Optional tests can be enabled in the whole run of the program, with the --enable-optional-test flag.

A test can also be enabled on a per-object basis, by adding the annotation kube-score/enable to the object. The value should be a comma-separated string of the test IDs.

Example:

Testing this object will enable the container-seccomp-profile test. Also, multiple tests defined by kube-score/ignore are also ignored at the same.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: optional-test-manifest-deployment
  labels:
    app: optional-test-manifest
  annotations:
    kube-score/ignore: pod-networkpolicy,container-resources,container-image-pull-policy,container-security-context-privileged,container-security-context-user-group-id,container-security-context-readonlyrootfilesystem,container-ephemeral-storage-request-and-limit
    kube-score/enable: container-seccomp-profile
spec:
  replicas: 1
  selector:
    matchLabels:
      app: optional-test-manifest
  template:
    metadata:
      labels:
        app: optional-test-manifest
    spec:
      containers:
      - name: optional-test-manifest
        image: busybox:1.34
        command:
        - /bin/sh
        - -c
        - date; env; tail -f /dev/null

Building from source

kube-score requires Go 1.21 or later to build. Clone this repository, and then:

# Build the project
go build ./cmd/kube-score

# Run all tests
go test -v ./...

Contributing?

Do you want to help out? Take a look at the Contributing Guidelines for more info. 🤩

Dependencies

Project	Version
go.dev	^1.21

Made by

kube-score's Issues

NetworkPolicies

Validate that each pod has a matching netpol

Warn if startingDeadlineSeconds is not set on CronJobs

readiness and liveness checks should not be identical

First off: thanks for this tool! Gonna use it in our CI. 😃 ❤️

My question: what are the recommendations based on? Is there a guide to best practices somewhere?

More specifically:

"Container probes, both readiness and liveness checks should be configured, and should not be identical".

I fail to see the harm in having identical readiness/liveness checks? It's done in the official documentation as well: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-tcp-liveness-probe

In our case this is a HTTP health check. You could even argue they are not identical, both initialDelaySeconds and timeoutSeconds are different.

Security Context at PodLevel not evaluated

Which version of kube-score are you using?

kube-score version: [e.g. 0.3.0]

master

What did you do?
See: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
  labels:
    app: test
spec:
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      securityContext:
        fsGroup: 65534
        runAsUser: 65534
      containers:
      - name: test

What did you expect to see?

securityContext from PodLevel gets recognized as a ContainerLevel securityContext

What did you see instead?
kube-score recommends to set a ContainerLevel securityContext

Include version information in the binary

Add a new sub-command: kube-score version, the program should output the version of kube-score used, such as kube-score version: 0.6.0 and exit.

If the program is built from source, use the version development.

"Ingress targets Service" has no test coverage

Recommend having a PodDisruptionBudget

PodDisruptionBudget (policy/v1beta1) are required to be able to safely drain multiple nodes at the same time without affecting availability of pods.

Feature: Ignore tests via object annotations

Currently it's only possible to ignore a test on the whole test run, with the --ignore-test flag.

My suggestion of how to get more fine controlled ignores, is to add annotation support for this.

kube-score can look for the annotation kube-score/ignore in every object that it's parsing, and ignore the tests for only that object.

A full example would look like this:

version: v1
kind: Service
metadata:
  annotations:
    kube-score/ignore: service-type,stable-version

Add pre-built docker image

To make adaptation in CI/CD systems easier

Push docker images with goreleaser

Currently the versioned tags are pushed manually, by pulling :latest and retagging it.

This could be done as a part of the goreleaser process.

Keeping the existing docker building on CircleCI is not a requirement if it doesn't fit anymore.

Allow limits to be optional

Describe the feature
Ability to ignore just the limits and not the requests.

Expected behavior
In our environment we want to require requests, but we leave limits optional.

Support directory as input

Support for iterating through all templates in a directory. *.yaml works great when you don't have subdirectories of yaml files.

Ignore CronJob probes

Describe the bug
CronJobs are highly likely to not have a readiness or liveness concept as they are typically not hooked up to a service. It likely makes sense to either ignore them for probes or to have them at a different level or an optional way to disable them.

To Reproduce

Have a cron job without a probe and run kube-score

Expected behavior
Ability to ignore missing cronjob probes

API for usage by other tools

Define a public API that can be used by other tools.

check for nodeport usage in service is missing

Describe the bug
We'd like to prevent usage of nodeport in our services. Currently there is no check for this.

Reason: https://oteemo.com/2017/12/12/think-nodeport-kubernetes/

To Reproduce

Insert a YAML document that triggers the incorrect behaviour

Expected behavior
A clear and concise description of what you expected to happen.

Version
kube-score version: [e.g. 0.3.0]

Additional context
Add any other context about the problem here.

Container image pull policy is asking for an invalid value

My YAML container image pull policy says:
imagePullPolicy: Always

and kube-core is recommending "PullAlways" value
[CRITICAL] Container Image Pull Policy
* esp -> ImagePullPolicy is not set to PullAlways
It's recommended to always set the ImagePullPolicy to PullAlways, to make sure that the imagePullSecrets are always correct, and to always get the image you want.

however, that is not a valid value according to latest API definition:
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.12/

Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated. More info: https://kubernetes.io/docs/concepts/containers/images#updating-images

Feature Request JSON Output

kube-score is pretty cool, is it possible to get JSON output? With JSON output it could be easily integrated with other things such as vscode etc.

Network Policy: Make sure that it targets a Pod

All incoming NetworkPolicies should target at least one Pod, if not return a critical error.

Feature Request: verbose output should show all tests

During testing (e.g. new templates, new tests, etc.) I'd like to be able to pass verbose to see all of the possible tests and if / why they were skipped.

Example:
[OK] Deployment has host PodAntiAffinity * Skipped Skipped because the deployment has less than 2 replicas

In specific this came up when implementing a new test that was not being applied due to the apiVersion configured in the template causing the section of the template to be skipped. A message such as:
[OK] New Test Here * Skipped Skipped because the apiVersion is not in: (list of matching versions)

Another possible enhancement would be to implement a custom "skipped" status, or similar, instead of "OK"

support for `kind: List`

Please support kind: List for the input so that we can also run kube-score on an existing cluster for adhoc checks.

$ kubectl get all -n monitoring -o yaml | kube-score score -
$ kubectl get all -n monitoring -o yaml | kube-score score - --v
2019/01/15 13:15:24 Unknown datatype: List
$ kubectl get all -n monitoring -o json | jq '.items="<...redacted...>"'
{
  "apiVersion": "v1",
  "items": "<...redacted...>",
  "kind": "List",
  "metadata": {
    "resourceVersion": "",
    "selfLink": ""
  }
}
$ 

Here is a hacky work around:

$ kubectl get all -n monitoring -o yaml | sed -e 's/^- /---\n  /g' | kube-score score -
v1/Pod alertmanager-main-2 in monitoring
    [OK] Stable version
    [CRITICAL] Container Image Pull Policy
        * alertmanager -> ImagePullPolicy is not set to Always
             It's recommended to always set the ImagePullPolicy to Always, to make sure that the imagePullSecrets are always correct, and to always get the image you want.
...

Disable tests that you don't need

No Kubernetes cluster is similar to the next one, and kube-score should be adaptable so that everyone can use it. While still keeping sane defaults.

I'll add a flag --disable-test that can be specified multiple times to disable all of the tests that you need. Another flag --list-tests will print a list of all tests, to make it easy to know which tests that you might want to disable.

Issue #46 and #48 are both related to this.

Don't require probes on all containers in a pod

It doesn't make sense for initContainers, and a common use case is to only have probes on one container.

PodSpec: Security policies

Openshift objects validation

Hello, it will be nice, if kube-score will validate openshift objects: Route (Ingress analog) and DeploymentConfig (Deployment analog)

Container Image Pull Policy - Always vs. IfNotPresent

First, thanks for starting this project. It's really neat.

It would be nice to to have certain test configurable - e.g. Container Image Pull Policy

Looking at the helm charts the majority is using IfNotPresent as it's default.

find . -name values.yaml -print0 | xargs -0  git grep "imagePullPolicy:" | grep IfNotPresent | wc -l                                               
      54
find . -name values.yaml -print0 | xargs -0  git grep "imagePullPolicy:" | grep Always | wc -l                                                
       4

Personally I would argue, that Always needs to be set when :latest or some other static tag is specified. IfNotPresent is advantageous as it reduces pod restart times and does not introduce a a hard dependency to the docker registry when restarting pods.

Should throw error on invalid label values

Which version of kube-score are you using?

kube-score version: registry.gitlab.com/warmfusion/kube-score:0-7-0

What did you do?

Validated the following yaml with an invalid label value;

apiVersion: v1
kind: Service
metadata:
  name: alertmanager
  labels:
    app.kubernetes.io/managed-by: "engineering/kustomize"
spec:
  type: ExternalName
  externalName: alertmanager.example.com

What did you expect to see?

A critical error indicating that the value of the label is not compatible with kubernetes.

What did you see instead?

No mention of any errors;

$ cat test.yaml
apiVersion: v1
kind: Service
metadata:
  name: alertmanager
  labels:
    app.kubernetes.io/managed-by: "engineering/kustomize"
spec:
  type: ExternalName
  externalName: alertmanager.example.com


$ docker run -it --rm -v $(pwd):/app registry.gitlab.com/warmfusion/kube-score:0-7-0 kube-score score /app/test.yaml
v1/Service alertmanager
    [OK] Stable version
    [OK] Service Targets Pod
    [OK] Service Type


$ docker run -it --rm -v $(pwd):/app registry.gitlab.com/warmfusion/kube-score:0-7-0 kube-score version
kube-score version: 0.7.0, commit: bc8f6ac008072bea3c33707f9d4a58265b1de30c, built: 2019-04-28T13:03:35Z

idea: automatically inject improvements

Many tests could easily modify the input object to add the improvements automatically.

For example the "X-has-host-podantiaffinity" tests:

With an input like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: foobar
spec:
  replicas: 10
  template:
    metadata:
      labels:
        app: foo
    spec:
      containers:
      - name: foobar
        image: foo:bar

The following affinity rule could be added fairly easily:

      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchLabels:
                  app: foo
                topologyKey: kubernetes.io/hostname

The hardest part with this, is to preserve as much of the original YAML (comments etc) as possible. I don't know at the moment if there are any tools that will make this easier.

Failing when use ExternalName in Service

---
apiVersion: v1
kind: Service
metadata:
  name: wp-site
  namespace: site
spec:
  externalName: wp.example.com
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  type: ExternalName

Output:

v1/Service wp-site in site
    [OK] Stable version
    [CRITICAL] Service Targets Pod
        * The services selector does not match any pods

PodSpec: Explicit image version

Service: Make sure that it targets a Pod

PodSpec: ImagePullPolicy

Flag to disable checking network policy.

Hello!
I use calico network policy definition (https://docs.projectcalico.org/v3.2/reference/calicoctl/resources/networkpolicy).
And until somebody adds support for calico, unfortunately, I can't use kube-score in my CI/CD.

Let a specific version of Kubernetes be specified when kube-scoring a file

e.g. a warning like the below is emitted when kube-scoring a Deployment file

    [WARNING] Stable version
        * The apiVersion and kind extensions/v1beta1/Deployment is deprecated
             It's recommended to use apps/v1 instead

Deprecation information is Kubernetes version-specific I'm guessing, so this warning should depend on the version of Kubernetes being used.

Named ports are not supported

Which version of kube-score are you using?

kube-score version: 0.7.1

What did you do?

I was writing some manifests file to describe a service for one of my Kubernetes cluster. I used named ports. When I apply the manifests it works perfectly, but my CI which use kube-score seems not to be happy.

Here is a simple example manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: nginx
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        imagePullPolicy: Always
        ports:
        - name: http
          containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: nginx
  name: nginx
spec:
  ports:
  - name: http
    port: 80
    targetPort: http
  selector:
    app.kubernetes.io/name: nginx
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  labels:
    app.kubernetes.io/name: nginx
  name: nginx
spec:
  rules:
  - host: nginx.my-cluster.local
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx
          servicePort: http

And run the following command:

kube-score score manifest.yaml \
    --ignore-test pod-probes \
    --ignore-test deployment-has-host-podantiaffinity \
    --ignore-test container-security-context \
    --ignore-test pod-networkpolicy \
    --ignore-test deployment-has-poddisruptionbudget \
    --ignore-test container-resources

It fails.

If I change the servicePort from http to 80 in the Ingress and remove the name of the port specified in the Service, then it will pass.

What did you expect to see?

Here is the output I got when I use numerical ports instead of named ones:

extensions/v1beta1/Ingress nginx
    [OK] Ingress targets Service
    [OK] Stable version
apps/v1/Deployment nginx
    [OK] Stable version
    [OK] Container Image Tag
    [OK] Container Image Pull Policy
v1/Service nginx
    [OK] Stable version
    [OK] Service Type
    [OK] Service Targets Pod

It should give the same output using numerical or named ports.

What did you see instead?

extensions/v1beta1/Ingress nginx
    [CRITICAL] Ingress targets Service
        * / -> No service match was found
             No service with name nginx and port 0 was found
    [OK] Stable version
apps/v1/Deployment nginx
    [OK] Stable version
    [OK] Container Image Tag
    [OK] Container Image Pull Policy
v1/Service nginx
    [OK] Stable version
    [OK] Service Targets Pod
    [OK] Service Type

Friendlier file-not-found errors

If kube-score is invoked correctly, there is a risk of being treated with a Go-panic.

$ ./kube-score f
panic: open f: no such file or directory

goroutine 1 [running]:
main.scoreFiles(0xc0001f8100)
	/Users/gustav/src/kube-score/cmd/kube-score/main.go:131 +0x1b6d
main.main()
	/Users/gustav/src/kube-score/cmd/kube-score/main.go:44 +0x1a4

The error message should be improved to something like this:

Unable to parse "f" (open f: no such file or directory)

improve usability and documentation of kube-score --ignore-test

Describe the bug
To understand what are the valid values for kube-score --ignore-test you have either to read the source code or guess what might be a correct one.

To Reproduce
Try to suppress some failed checks without knowing what are the options

Expected behavior
Having a list of valid values.

Ideally you could also give each check a UID as in hadolint or shellcheck and suppress them with kube-score --ignore-test KS0017, KS0033, a .kube-score.yaml

ignored:
  - KS0017
  - KS0033

or as ENV like KUBESCORE_OPTS="--ignore-test KS0017, KS0033".

(Concepts shamelessly stolen at hadolint and shellcheck 😃)

Version
kube-score version: 0.4.0

Additional context
These are the ones that I found (as reminder to myself)

• container-image-pull-policy
• container-image-tag
• container-resources
• container-security-context
• cronjob-has-deadline
• deployment-has-poddisruptionbudget
• ingress-targets-service
• networkpolicy-targets-pod
• pod-networkpolicy
• pod-probes
• service-targets-pod
• service-type
• stable-version
• statefulset-has-poddisruptionbudget

score: recommend setting hostname podAntiAffinity

Recommend setting a podAntiAffinity on Deployments and StatefulSets:

Either a preferredDuringSchedulingIgnoredDuringExecution or a requiredDuringSchedulingIgnoredDuringExecution anti affinity with the kubernetes.io/hostname key should be set.

Setting this prevents all pods in a deployment from being scheduled on the same node if there are other nodes available.

spec:
  template:
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
           - topologyKey: "kubernetes.io/hostname"

Probes: Don't warn for missing readinessProbes if the pod isn't targeted by a Service

kube-score/ignore ignored on pod definition.

Describe the bug
kube-score/ignoreannotation ignored on pod definition.

To Reproduce

kube-score score pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: "release-name-chart-test-connection"
  labels:
    app.kubernetes.io/name: chart
  annotations:
    kube-score/ignore: pod-networkpolicy,pod-probes
spec:
  containers:
    - name: wget
      image: busybox:1
      command: ['wget']
      args:  ['release-name-chart:80']
      imagePullPolicy: Always
      resources:
        limits:
          cpu: 100m
          memory: 64Mi
        requests:
          cpu: 50m
          memory: 32Mi
  restartPolicy: Never

Expected behavior
No error should be returned.

Version
kube-score version: 0.5.0

Remove the backwards compatible scoring

When the kube-score score file.yaml sub-command was introduced in v0.5.0, the ability to usekube-score file.yaml remained.

This backwards compatibility should be removed.

Container Image Pull Policy: does not print a description in case of error

Describe the bug
A clear and concise description of what the bug is.

The "Container Image Pull Policy" check does not print a description in case of a critical error.

To Reproduce

apiVersion: apps/v1
kind: Deployment
metadata:
  name: foo
  namespace: bar
spec:
  replicas: 1
  selector:
    matchLabels:
      app: foo
  template:
    metadata:
      labels:
        app: foo
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 65535
        runAsGroup: 65535
        fsGroup: 65535
      containers:
      - name: foo
        image: foo:latest
        securityContext:
          readOnlyRootFilesystem: true
        resources:
          requests:
            memory: "50Mi"
            cpu: "50m"
          limits:
            memory: "100Mi"
            cpu: "100m"

Expected behavior

An explanation of why the check is failing should be returned.

Version
kube-score version: master

PodSpec resouces.limits.cpu is controvercial

Many Kubernetes users [citation needed] advise setting a CPU limit as it can cause "buggy" behavior in CFS.

Figure out if that is correct, and if kube-score should continue to issue a critical warning if a CPU limit has not been set.

Windows support

Is it possible to install kube-score on Windows?

Problem with parsing multi dashes

Hi,

I have configMaps which keep data with multiple dashes. It raises an error when I try to use kube-score with that.

---

apiVersion: v1
kind: ConfigMap
metadata:
  name: awesome
data:
  awesome.crt: |
    -----BEGIN CERTIFICATE-----
    TEST_DATA
    -----END CERTIFICATE-----
---
>> kube-score test_configmap.yaml
panic: yaml: unmarshal errors:
  line 1: cannot unmarshal !!str `TEST_DA...` into score.detectKind

goroutine 1 [running]:
main.main()
        /path/cmd/kube-score/main.go:78 +0x17c5

Type: StatefulSet

Type: DaemonSet

Minor improvements on the CI

Hi! Thank you for your great tool!

I would like to propose some minor improvements on the building/CI.
Firstly it would be great to have a Dockerfile that builds and runs the kube-scope in a multi layer docker build so as to be easier for someone to download and use the tool without having to setup GO in his/her env (or easily test some changes when changing code).

Secondly based on the above you could have circle CI pushing the latest code under a latest tag on DockerHub so someone doesn't even has to build anything, just gets the docker image and starts using the latest code of the tool.

I have done both of the above in the past so I would be more than happy to contribute if you think these proposals could be useful.

Improve CI/CD friendliness

It's already possible to run kube-score as a CI/CD step, and the program will exit with code 1 in case of critical errors, or on warnings if the --exit-one-on-warning flag is used.

• Add an example of how to use with Helm charts / helm template
• Document available flags
• Add configuration to disable some steps
• Add configuration to change the "score" a check

Make sure that Ingress (extensions/v1beta1) targets a Service

PodSpec: Image hash