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 !