Feature request: a configuration file

[alexppg]

It would be awesome to have the possibility to have a .kube-score.yml file in which we could configure whatever we need. I think at the time it would mostly be tests to ignore, but it may be interesting for the future.

This might serve as inspiration: https://docs.kubelinter.io/#/configuring-kubelinter

PD: Thanks for your work, kube-score is awesome!

[day1118]

This would make using CI much easier, rather than having a long command line full of flags.

[kmarteaux]

@alexppg, @day1118, and @zegl

I have been playing around with this, since I agree a configuration file would be useful. My current local implementation is to generate the configuration file on-demand (kube-score mkconfig). The configuration file directives could be overridden at command line, preserving existing functionality/behavior. For example, one could still exclude a test using the --ignore-test flag without editing .kube-score.yml.

At present, the configuration looks as such --

$ ./kube-score mkconfig
$ cat ./kube-score.yml
(### BTW I know this isn't actually valid YAML yet. I'm still trying to settle on what it should look like ###)

object: CronJob
checks:
- check: cronjob-has-deadline
status: "on"

object: Deployment
checks:
- check: deployment-has-poddisruptionbudget
status: "on"
- check: deployment-has-host-podantiaffinity
status: "on"
- check: deployment-targeted-by-hpa-does-not-have-replicas-configured
status: "on"
- check: deployment-pod-selector-labels-match-template-metadata-labels
status: "on"

object: HorizontalPodAutoscaler
checks:
- check: horizontalpodautoscaler-has-target
status: "on"

object: Ingress
checks:
- check: ingress-targets-service
status: "on"

object: NetworkPolicy
checks:
- check: networkpolicy-targets-pod
status: "on"

object: Pod
checks:
- check: container-resources
status: "on"
- check: container-resource-requests-equal-limits
status: "off"
- check: container-cpu-requests-equal-limits
status: "off"
- check: container-memory-requests-equal-limits
status: "off"
- check: container-image-tag
status: "on"
- check: container-image-pull-policy
status: "on"
- check: container-ephemeral-storage-request-and-limit
status: "on"
- check: container-ephemeral-storage-request-equals-limit
status: "off"
- check: container-ports-check
status: "off"
- check: pod-networkpolicy
status: "on"
- check: pod-probes
status: "on"
- check: container-security-context-user-group-id
status: "on"
- check: container-security-context-privileged
status: "on"
- check: container-security-context-readonlyrootfilesystem
status: "on"
- check: container-seccomp-profile
status: "off"
- check: container-ephemeral-storage-requests-and-limits
status: "on"

object: PodDisruptionBudget
checks:
- check: poddisruptionbudget-has-policy
status: "on"

object: Service
checks:
- check: service-targets-pod
status: "on"
- check: service-type
status: "on"

object: StatefulSet
checks:
- check: statefulset-has-poddisruptionbudget
status: "on"
- check: statefulset-has-host-podantiaffinity
status: "on"
- check: statefulset-has-servicename
status: "on"
- check: statefulset-pod-selector-labels-match-template-metadata-labels
status: "on"

object: all
checks:
- check: stable-version
status: "on"
- check: label-values
status: "on"

Is this in line with what you were envisioning as a user?

[day1118]

Hi @kmarteaux - This is great news!

I had assumed the syntax would be as simple as matching the cli flags. This would make it very easy to follow and reason about:

disableIgnoreChecksAnnotations: false
enableOptionalTest:
 - test1
 - test2
ignoreTest:
 - test3
 - test4

I do think the syntax that you have proposed feels like overkill, but either way, I think it would be more natural to replace status: "on" with enabled: true

Thanks

[kmarteaux]

Anthony, thanks for the feedback. That is why I asked, it felt like I was overthinking it. I will adjust accordingly.

[alexppg]

I agree with @day1118. It seems a pretty understandable approach. Thanks @kmarteaux !