Consider allowing 'containers[*].securityContext.capabilities'

[markusthoemmes]

Expected Behavior

I can apply "common" security best-practices to my Knative Services.

Actual Behavior

I can't drop capabilities that I don't actually need.

Additional Info

Discussed this with @julz a bit on Slack, trying to summarize this here:

We've been careful in the past to try to only allow settings that make containers more secure, as operators could be relying on Knative to forbid certain fields (since it has done so in the past) and thus might not have created a PodSecurityPolicy or thelike to make sure people don't escalate their privileges.

As such, only allowing to drop capabilities would be incontentious as that would strictly make containers safer than before. Adding capabilities has the danger of people doing stuff they couldn't do before so at the very least that'd need to be guarded by a feature gate. I'm not sure if the current kubernetes.podspec-securitycontext can be used for this or if we'd need another feature gate that clearly states: "Make sure you have your PSPs in place when enabling this".

Some more information:
Dropping capabilities is somewhat redundant if you force running as non root and disallow escalation. However, still dropping all caps adds another layer to the onion, which to me seems like a good thing. "it’s also legit useful in the case where runAsUser is root" (@julz)

Proposal

1. Allow the drop part of the capabilities without a feature gate or at least behind the current kubernetes.podspec-securitycontext gate.
2. Create a new feature gate that guards "dangerous" settings (Priviledged and AllowPrivilegeEscalation and all the other settings could be allowed by this as well)

[evankanderson]

/area API
/good-first-issue
/kind feature
/triage accepted

[knative-prow-robot]

@evankanderson:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

/area API
/good-first-issue
/kind feature
/triage accepted

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[psschwei]

/assign @psschwei