Uh oh!
There was an error while loading. Please reload this page.
Run queue proxy with restricted profile - #13376
Conversation
| // Set PSP requirements explicitly to avoid failures in case `pod-security.kubernetes.io/enforce=restricted` is used | ||
| // at the user workload namespace | ||
| container.SecurityContext.AllowPrivilegeEscalation = ptr.Bool(false) |
There was a problem hiding this comment.
We don't allow the user to set the following two properties. So we enforce the defaults here to make it pass the PSP auditing.
There was a problem hiding this comment.
I sent #13401 to allow setting this in the Revision Spec (e.g. in Service).
Codecov ReportBase: 86.47% // Head: 86.47% // No change to project coverage 👍
Additional details and impacted files@@ Coverage Diff @@## main #13376 +/- ##
=======================================
Coverage 86.47% 86.47% =======================================
Files 196 196 Lines 14551 14551 =======================================
Hits 12583 12583 Misses 1669 1669 Partials 299 299
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. |
psschwei
left a comment
There was a problem hiding this comment.
Couple of minor things, but otherwise this looks good to me:
- could you add a release note?
- this won't work with kourier (it doesn't set runAsNotRoot = true)... don't think that blocks us here, just wanted to make a note of it
If you mean the gateway yes. I will take a look to fix it. Downstream we already run without root. |
@psschwei gentle ping, added the release note and created knative-extensions/net-kourier#934. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: psschwei, skonto The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
evankanderson
left a comment
There was a problem hiding this comment.
I think we may want to pass-through the allowPrivilegeEscalation and seccompProfile fields, and then add a feature flag to default them to safe values if not provided.
I hadn't hit on this until the other day seeming @mattmoor 's #13395 , but I think I'd feel most happy long term with "didn't set anything" meaning secure, but allowing people to explicitly be insecure when needed (maybe with warnings)
| // Set PSP requirements explicitly to avoid failures in case `pod-security.kubernetes.io/enforce=restricted` is used | ||
| // at the user workload namespace | ||
| container.SecurityContext.AllowPrivilegeEscalation = ptr.Bool(false) |
@evankanderson I also mentioned on slack that allowing users to configure stuff on their own was more user friendly than having everything explicitly set without ability to change on demand. Also as you said users can choose their security level. For some properties though you can be opinionated and set explicitly the defaults instead of optionally applying them as in #13398 as long as users can remove them. This can be done, given our experience of what users need in practice eg. usually you dont want a service to escalate privileges. Another approach is to define security application as a downstream issue only. We have options depending on the strategy, do we want to be secure by default? My understanding is that this concept applies to other features like internal-encryption etc. Btw I am not sure if @mattmoor was aware of this PR or discussion. Should I close this PR and enable all stuff in #13398 or keep this PR with the queue proxy changes only?
You get the warning anyways from psp no need to add more imho. |
| Drop: []corev1.Capability{"all"}, | ||
| Drop: []corev1.Capability{"ALL"}, | ||
| }, | ||
| SeccompProfile: &corev1.SeccompProfile{ |
There was a problem hiding this comment.
I guess this takes precedence compared to podsecurityContext.SeccompProfile.
evankanderson
commented
Oct 17, 2022
Can users see the PSP / PSA warnings when they apply a Knative Service? If so, then I'd agree about not needing a second set of warnings that settings are possibly dangerous. In #13399, I tried to add a warning because our future behavior might change, which could break a small number of applications. Upon reflection, I think giving the defaulting of security properties time to sit rather than rushing it for release is probably the right idea, particularly given the issues hit by #13399. |
evankanderson
commented
Oct 17, 2022
I'm still willing to approve the |
skonto
commented
Oct 17, 2022
/test istio-latest-no-mesh |
skonto
commented
Oct 18, 2022
@psschwei thank you, ok to unhold? |
psschwei
commented
Oct 18, 2022
/hold cancel |
* allow user workloads to run with restricted profile * only change queue proxy
* Run queue proxy with restricted profile (knative#13376) * allow user workloads to run with restricted profile * only change queue proxy * remove seccomp
…ve#1283) * Run queue proxy with restricted profile (knative#13376) * allow user workloads to run with restricted profile * only change queue proxy * remove seccomp
#13) * Run queue proxy with restricted profile (knative#13376) * allow user workloads to run with restricted profile * only change queue proxy * remove seccomp
…hift#1283) * Run queue proxy with restricted profile (knative#13376) * allow user workloads to run with restricted profile * only change queue proxy * remove seccomp
#19) * Run queue proxy with restricted profile (knative#13376) * allow user workloads to run with restricted profile * only change queue proxy * remove seccomp Co-authored-by: Stavros Kontopoulos <skontopo@redhat.com>
Fixes partially #13308
Proposed Changes
Release Note