Feature Request: Ignore certain fields

[EsDmitrii]

Hi!
I have started using this great tool and have encountered some problems that need to be solved:

1. I am using ArgoCD with some plugins, for example the Vault plugin. Argocd before deployment, when it templates manifests, it accesses the vault to get the secrets in the path described in the manifest.
   When the manifest is checked by the kubectl-validate tool, it triggers the error like this:

Secret.core "secretnamehere" is invalid: [<nil>: Invalid value: "": "data.pass" must validate at least one schema (anyOf), data.pass: Invalid value: "<path:projects/data/path/to/secret/in/vault/#pass>": data.pass in body must be of type byte: "<path:projects/data/path/to/secret/in/vault/#pass>", <nil>: Invalid value: "": "data.pass" must validate all the schemas (allOf). None validated]

Because manifests are not yet rendered by ArgoCD and they contain paths to the Vault secret like in Helm scheme.
Is there any way to skip checks with magic comment like in kics or any other ways:)
I ask this because now I get a lot invalid errors in CI.

2. Is there any way to create reports for integrate with CI? For example SAST, xml, etc (I use GitlabCI).
   This is nice to have to track issues

[alexzielenski]

Making sure I understand this issue correctly:

1. Seems like you have some fields which are post-processed by ArgoCD, you want to skip validation of these fields. Would it render the files locally?
2. The tool does have an option --output json which may be helpful for this use case

[EsDmitrii]

Hi! 1. Yes, you’re right. It would be nice to have to skip checks of some lines in file. I use plugin for Argo that goes to the hashicorp vault, takes secrets and paste it to target manifest. For example to ConfigMap, secret, etc. I use it to keep secret data secure and not to store it in git. Manifest in git contains path to secret in vault that Argo should take while applying app to k8s 2. If json output supports Code Quality or test summary something like this on screenshot - ok, I’ll try it Screenshot link https://github.com/kubernetes-sigs/kubectl-validate/assets/124890665/2472e969-aa0c-4a3f-b1ce-e18f83e101b9

…

On Fri, 17 Nov 2023 at 01:24, Alex Zielenski ***@***.***> wrote: Making sure I understand this issue correctly: 1. Seems like you have some fields which are post-processed by ArgoCD, you want to skip validation of these fields. Would it render the files locally? 2. The tool does have an option --output json <https://github.com/kubernetes-sigs/kubectl-validate#json-output> which may be helpful for this use case — Reply to this email directly, view it on GitHub <#80 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A5Y24KLVWFEMMCCSHZFLGBTYE2HBLAVCNFSM6AAAAAA7IZ4GKKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJVGQYTANZXGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[alexzielenski]

Im hesitant to add support in the tool for this use case without seeing how others are using preprocessors. I'm changing the issue title to better reflect this use case of ignoring certain fields, so otheres can post their usage stories. For now I believe this can be worked around by post processing the errors to remove errors for such fields, (or preprocessing the input with dummy secrets)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[alexzielenski]

/remove-lifecycle stale
/lifecycle frozen

[alexzielenski]

It should be possible to augment desired schemas to add opaque fields using --overlay-schemas. Inject a subschema for the field you want to ignore using x-kubernetes-preserve-unknown-fields