<p>In our kubernetes cluster setup, we normally have 2 types of setups: <code>prod</code> and <code>dev</code>. The clusters have tags/labels as well as env variables to identify them as such.</p>
<p>Some of our images are designed to dev but not prod and vice-versa (differences are in the custom binaries that are installed within the org). Right now, when the pods start , they do not fail at startup but are functionally useless because the accurate binaries are missing. Is there a way to prevent a prod pod to not start with an image named dev (and vice-versa)</p>

<p>Kubernetes provides a few ways to enforce your organizational policies, some are as follow:</p>
<p><strong>using ImagePolicyWebhook:</strong></p>
<p>You can use <code>ImagePolicyWebhook</code> to enforce your image usage policies by doing <code>ImageReview.</code> More info <a href="https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook" rel="nofollow noreferrer">here</a>.</p>
<p><strong>Using validation webhook:</strong></p>
<p>A <code>validation webhook</code> intercepts the request for pod creation, You can write your business logic in the webhook code, and it will enforce using the admission review. You can find more <a href="https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/" rel="nofollow noreferrer">here</a> and <a href="https://technekey.com/what-is-validation-webhook-in-kubernetes/" rel="nofollow noreferrer">here</a>.</p>
<p><strong>Using OPA Gatekeeper:</strong></p>
<p>Alternatively, you may use <code>OPA Gatekeeper</code> for policy enforcement. You can get more info <a href="https://kubernetes.io/blog/2019/08/06/opa-gatekeeper-policy-and-governance-for-kubernetes/" rel="nofollow noreferrer">here</a>.</p>
<p>Note that each option listed above are huge topic on its own. You might need to choose the best-suited option for your use case.</p>
