<p>I would like to do server-side validation of Kubernetes yaml files before applying them.</p>
<p>I know that in my Jenkins agent, I could use the following kubectl command for validating yaml files at the server-side but I am a bit concerned about access-control:</p>
<ul>
<li>Kubernetes &lt; v1.18:
<code>kubectl apply --server-dry-run -f ...</code></li>
<li>Kubernetes &gt;= v1.18:
<code>kubectl apply --dry-run=server -f ...</code></li>
</ul>
<p>The Kubernetes documentation says the following:</p>
<blockquote>
<p>Authorization for dry-run and non-dry-run requests is identical. Thus,
to make a dry-run request, the user must be authorized to make the
non-dry-run request.</p>
</blockquote>
<p>I don't want any Jenkins agents to have super powers over my EKS cluster. A bad actor could use my Jenkins agent maliciously and apply any manifests they wanted. Right now for security/stability/management reasons, creating Kubernetes objects is done by a different system not Jenkins.</p>
<p>I checked a few other options but I can see drawbacks:</p>
<ul>
<li>Kubeval is not aware of any CRDs installed in the actual cluster.</li>
<li>Client Validation is not really end-to-end validation</li>
<li>I could develop a rest api that exposes a validation rest endpoint and hits Kubernetes APIs or runs a kubectl <code>--run-dry</code> under the hood. However, this requires more dev work than we have capacity for.</li>
</ul>
<p>Do you have any ideas or are you aware of any validation tools that I could use in our CI system securely for the purpose of validating end-2-end Kubernetes yaml files?</p>

<p>I've been looking for this myself and did not find a sufficient tooling. However, there are few workarounds:</p>
<ul>
<li>Deploy all objects to a <em>temporary</em> <code>ci-job-id</code> namespace in dev/stage clusters. They should be the same as a prod, but will not impose the security risks you mentioned. This gives an additional benefit - you can check if everything got created, all pods are running. It helps to catch issues like insufficient resource requests, missing images, misconfigured <code>Service</code> selectors, etc. Also it let's you add a smoke test on top.</li>
<li>Spin a small minikube with all the CRDs specifically for CI validations. This approach gives you less coverage, but it is much cheaper to maintain.</li>
</ul>
