Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

It is not easy to determine when securityContext.allowPrivilegeEscalation can be set to false. The minimal requirement is for the securityContext.privileged to be set to false and CAP_SYS_ADMIN/SYS_ADMIN to not be part of securityContext.capabilities.add. However the container might still require securityContext.allowPrivilegeEscalation: true.

/test pull-gardener-e2e-kind-ipv6

It is not easy to determine when securityContext.allowPrivilegeEscalation can be set to false. The minimal requirement is for the securityContext.privileged to be set to false and CAP_SYS_ADMIN/SYS_ADMIN to not be part of securityContext.capabilities.add. However the container might still require securityContext.allowPrivilegeEscalation: true.

Couldn't we add an opt-out option of the webhook with a label that can be set on Pods in order to not trigger it when it cannot be set to false? We have such an approach for other, similarly working webhooks

Maybe this was already discussed, but why don't we do this via a webhook in GRM? We could augment https://github.com/gardener/gardener/tree/master/pkg/resourcemanager/webhook/seccompprofile (rename) to also handle this AllowPrivilegeEscalation field in pod specs (maybe even also other simple things from the component checklist)?
Doing this manually and expecting others to be aware of it will probably lead to deficiencies, don't you think?

For the seccomp profile field, the GRM webhook only covers the Seed/Garden cluster. For Shoots, we declaratively set the field. IIRC, the plan was even to drop the GRM webhook for the Seed/Garden cluster and use the corresponding kubelet field in the Shoot spec (for ManagedSeeds at least).

The advantage of a webhook is that there won't be need to adapt each and every container. However, exceptions still have to be done - most likely via label/annotation to instruct the webhook to do not mutate in special cases when the workload needs privilege escalation for example.
The work for the developer at the end is the same. Via the webhook or not, the workload has to be tested whether it works with allowPrivilegeEscalation=false or not.

There was a push on #7157 or a similar issue on why we, from Gardener Core side, didn't do anything so far on the topic. However, my reply back then was that:

• The requirements to me are not clear. Do we want to enforce such security settings on the runtime (with webhooks) or are we fine only to have them declaratively.
• There is not only 1 single setting - seccomp profile, run as non-root, allowPrivilegeEscalation=false, etc. If we do it via a webhook, then we might want to take care for every field.

We also have diki that performs the checks, so it won't be the case that we missed to adapt a component.

And, the webhook approach - it introduces a performance penalty (n milliseconds for the webhook call, network cost, etc) and yet another failure point in the system.

tl;dr: I don't see super big advantage of using a webhook if we don't have the requirement to enforce the fields on the runtime (kyverno-like). But I am open to discuss and see other points.

/test pull-gardener-integration

/test pull-gardener-e2e-kind-ipv6

Holding this PR until we have clarity on what approach to use for the containers.securityContext.allowPrivilegeEscalation field.
/hold

/unhold

LGTM label has been added.

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ialidzhikov

The full list of commands accepted by this bot can be found here.

The pull request process is described here