Feature: Let users set allowPrivilegeEscalation = false on ksvc.

[mattmoor]

🎁 This allows used to specify allowPrivilegeEscalation (in particular to false) to ensure that processes cannot escalate privileges.

Kicking the tires on the new GKE security posture dashboard, I noticed that ~all Knative services get flagged for this despite Knative not allowing me to set it to false!

https://cloud.google.com/kubernetes-engine/docs/concepts/about-security-posture-dashboard

/kind bug

Knative services can now specify securityContext.allowPrivilegeEscalation

/cc @dprotaso @evankanderson @psschwei

[codecov]

Codecov Report

Base: 86.43% // Head: 86.45% // Increases project coverage by +0.01% 🎉

Coverage data is based on head (1c01bd9) compared to base (f9a75d7).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #13395      +/-   ##
==========================================
+ Coverage   86.43%   86.45%   +0.01%     
==========================================
  Files         196      196              
  Lines       14549    14551       +2     
==========================================
+ Hits        12576    12580       +4     
+ Misses       1673     1671       -2     
  Partials      300      300              

Impacted Files	Coverage Δ
pkg/apis/serving/fieldmask.go	95.56% <100.00%> (+0.01%)	⬆️
pkg/reconciler/revision/background.go	89.09% <0.00%> (-1.82%)	⬇️
pkg/autoscaler/scaling/multiscaler.go	88.59% <0.00%> (+1.34%)	⬆️
pkg/reconciler/configuration/configuration.go	84.36% <0.00%> (+1.42%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[evankanderson]

Does the GKE security posture dashboard line up with the Pod Security Standards published by Kubernetes (and the Pod Security Admission feature in 1.24 and 1.25)?

I couldn't see any indication either way.

I wish that Kubernetes had a reasonable way of turning on these security features automatically for users. In particular, the restricted profile requires the following entries:

allowPrivilegeEscalation: false
runAsNonRoot: true
seccompProfile:
  type: RuntimeDefault  # or Localhost
capabilities:
  drop: [ALL]

The baseline profile allows the above fields to be undefined as well as the "safe" values.

With the exception of runAsNonRoot (which may break many user containers, I wonder if defaulting in the following would be reasonable if fields are unset):

allowPrivilegeEscalation: false
seccompProfile:
  type: RuntimeDefault  # or Localhost
capabilities:
  drop: [ALL]
  add: [NET_BIND_SERVICE]  # allow bind to low ports as non-root

I think we might want to put this behind a feature flag, and flip the flag forward for the January release (1.9).

[evankanderson]

/lgtm
/approve

I'll see about sending a PR for the feature to default to more secure.

An extra-bonus that I'll look at later is pulling the effective user ID when we resolve the OCI image; if the userId is non-zero or specified as non-zero in the SecurityContext, I can set runAsNonRoot: true to allow Knative Services to run under the restricted profile by default, which would be nice.

[knative-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: evankanderson, mattmoor

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

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/apis/OWNERS [evankanderson]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mattmoor]

An extra-bonus that I'll look at later is pulling the effective user ID when we resolve the OCI image; if the userId is non-zero or specified as non-zero in the SecurityContext, I can set runAsNonRoot: true to allow Knative Services to run under the restricted profile by default, which would be nice

@evankanderson one gotcha with this is that the user can be specified as either USER 1234 or USER nonroot. The latter requires reading /etc/passwd, which in the worst case requires fetching the entire image 😞 (and I think used to upset some PSP enforcement). This is why we default to numeric USER in Chainguard Images fwiw.

[mattmoor]

I didn't realize y'all had forked the source of truth for our fieldmasking, so unfortunately this missed the CRD schema 😞

I'll send a PR to update that shortly, so the CRD configs include these fields.