Narrow down the security profile of queue-proxy containers

[markusthoemmes]

Proposed Changes

Akin to our "main" deployments, this also narrows down the security surface of our queue-proxy containers. They shouldn't need any special capabilities.

Release Note

queue-proxies are no longer allow to run as root, they have a read-only root filesystem and have all capabilities dropped.

/assign @mattmoor @vagababov

[mattmoor]

/lgtm

[codecov]

Codecov Report

Merging #9974 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #9974   +/-   ##
=======================================
  Coverage   87.78%   87.78%           
=======================================
  Files         183      183           
  Lines        8631     8631           
=======================================
  Hits         7577     7577           
+ Misses        803      802    -1     
- Partials      251      252    +1     

Impacted Files	Coverage Δ
pkg/reconciler/revision/resources/queue.go	100.00% <ø> (ø)
pkg/reconciler/configuration/configuration.go	86.71% <0.00%> (-1.57%)	⬇️
pkg/activator/net/revision_backends.go	91.40% <0.00%> (+0.90%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b30c3c1...c7beac2. Read the comment docs.

[markusthoemmes]

Coming to think about it, maybe the QP actually has to have some caps to generate the socket to become ready 🤔

[mattmoor]

@markusthoemmes could we put it on a volume? 🤔

cc @julz

[markusthoemmes]

@mattmoor yeah I'm just investigating what the smallest surface area is. Disabling the readOnlyFilesystem fixes things so that should be easyish to resolve.

[julz]

Volume might work, but thinking out loud that might up exposing more surface area (trade offs) because then eg the PodSecurityPolicy will need to allow that volume type. Also I think volumes are pod level so we have to be careful a user can't sneakily add a volumemount to their user container (admittedly we don't allow those.. yet) and get access to the socket :/

[julz]

I would love us to be able to enable read-only filesystems though, to the extent that Im kind of regretting introducing the unix socket tbh :D

[markusthoemmes]

@julz yeah, you're voicing exactly what my quick research brought 😂.

I toyed adding an emptyDir volume with medium: Memory even but 🤷. Maybe we can do something via kodata here though!

[julz]

wonder if we could use an abstract socket and avoid the filesystem 🤔. downside: I think they're shared across the network namespace, in which case it'd be visible in user container :( - might be ok if it's only hosting a readiness endpoint, tho.

[markusthoemmes]

I'll play with it a little more, meanwhile I guess we could ship this with a writeable filesystem for now and play with alternatives separately.

[julz]

/lgtm

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: julz, markusthoemmes, 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/reconciler/OWNERS [markusthoemmes,mattmoor]

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

[markusthoemmes]

For the record: Abstract sockets seem to work, but I'd still like to keep the change separately so we can discuss sideeffects and stuff.