<p>If I have an existing cluster with existing resources and I create a new mutating webhook that needs to patch resources (e.g., adding a label to a namespace), once I create the mutating webhook all future resources get modified, but the ones already existing in the cluster do not. What is the best way of passing off existing resources (e.g., kube-system namespace) to the mutating webhook to get patched?</p>

Marcus
<p>As I know, you are not able to pass already deployed resources to <a href="https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook" rel="nofollow noreferrer">MutatingAdmissionWebhook</a>.</p>
<p>As an option that you most probably wont like, you can path <a href="https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#patch" rel="nofollow noreferrer">existing resources</a>.</p>
<p>In addition I would like to quote you <a href="https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#avoiding-operating-on-the-kube-system-namespace" rel="nofollow noreferrer">Avoiding operating on the kube-system namespace</a>  doc, as you mentioned  <code>kube-system</code> namespace:</p>
<blockquote>
<p>The <code>kube-system</code> namespace contains objects created by the Kubernetes
system, e.g. service accounts for the control plane components, pods
like <code>kube-dns</code>. Accidentally mutating or rejecting requests in the
<code>kube-system</code> namespace may cause the control plane components to stop
functioning or introduce unknown behavior. If your admission webhooks
don't intend to modify the behavior of the Kubernetes control plane,
exclude the <code>kube-system</code> namespace from being intercepted using a
namespaceSelector.</p>
</blockquote>
