Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend kubeconform to validate object names #142

Closed
dkulchinsky opened this issue Oct 19, 2022 · 2 comments
Closed

Extend kubeconform to validate object names #142

dkulchinsky opened this issue Oct 19, 2022 · 2 comments

Comments

@dkulchinsky
Copy link

Very nice tool! thanks for working on this 馃憤馃徏

I wonder if you'd consider adding validation of Object Names and IDs to ensure they conform with Kubernetes standards as described in https://kubernetes.io/docs/concepts/overview/working-with-objects/names/

for example, a volume named my_config should be rejected, while my-config should be valid

@eyarz
Copy link
Contributor

eyarz commented Oct 20, 2022

Some validations are not part of the K8s schema because they are performed on the cluster side. The object name validation is not a part of the K8s schema. Therefore, it's not validated by kubeconform.

There are two solutions for your use case:

  1. use kubectl --dry-run=server flag so it will perform the cluster (server) side validation
  2. use an external policy management tool (e.g. Datree, Kyverno, Conftest, etc.) and add this validation

Disclaimer: I'm contributing code to Datree's projects. I think Datree will be a perfect fit because it also includes schema validation by Kubeconform and adds custom rules capabilities so you can easily create a rule to validate the object name.
They already have a similar built-in rule to validate labels (It's the same format as the object name - RFC-1123/hostnames).

@dkulchinsky
Copy link
Author

Thanks for your reply @eyarz!

my main motivation was to run this in CI to catch anything that might fail to deploy later on (we use a GitOps deployment model), so kubectl --dry-run=server is not really an option.

we already use conftest for testing in CI, was looking to avoid the need to write all the tests myself 馃槃

Thanks for suggesting Datree! I'll take a look and perhaps we can add it out toolbox if it make sense and better fits this use case.

cheers,
Danny

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants