feat: Add dynamic admission controller section to scs 0217

[viccuad]

Dynamic Admission Controllers from Policy Engines constitute a special attack surface.

From the SIG security threat model, the majority of mitigations are implemented by policy engines and cluster operators.

But cluster providers must enable mutual TLS for secure consumption of Kubernetes API webhooks, and cluster operators must use a policy engine that authenticates against those TLS-terminated webhooks (not all policy engines do).

[viccuad]

As an example, here's the threat model for Kubewarden, and the documentation on how to generally configure a cluster API server & Kubewarden, or specifically configure both a K3s API server & Kubewarden as well.

[fkr]

I removed couple people from the review assignment, I don't have any insights into this topic.
Maybe @jschoone @janiskemper @batistein or others could comment / review this PR.

[batistein]

Makes sense for policy engines specifically. They see every admission request, sensitive data included, so the attack surface is real. No argument there.

But the blanket MUST is too broad for a few reasons:

1. Most SCS clusters don't run a policy engine. The requirement adds real operational overhead for clusters where this threat just doesn't exist.
2. ClusterIP + NetworkPolicies already make threats 8 & 9 quite hard to pull off. You'd need to already be inside the cluster network. That's not nothing.
3. --admission-control-config-file is painful across distributions. A hard MUST here is going to be difficult to conform to in practice.

Would make more sense to split it:

• MUST if a policy engine is deployed
• RECOMMENDED for everything else

That way the strong requirement lands where the risk actually is.

[fkr]

thanks @batistein for your commentary. Much appreciated!

[viccuad]

Would make more sense to split it:

* `MUST` if a policy engine is deployed

* `RECOMMENDED` for everything else

Totally agree here, that was the original intention indeed. There's no need to enable this K8s hardening feature if the underlying dynamic admission feature is not being used.

Added commit with a clarification, hope that's enough!