-
Notifications
You must be signed in to change notification settings - Fork 593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add securityContext to Knative Eventing core objects #5863
Add securityContext to Knative Eventing core objects #5863
Conversation
Codecov Report
@@ Coverage Diff @@
## main #5863 +/- ##
=======================================
Coverage 81.96% 81.96%
=======================================
Files 220 220
Lines 7458 7458
=======================================
Hits 6113 6113
Misses 918 918
Partials 427 427 Continue to review full report at Codecov.
|
b5f22ad
to
2b05b8a
Compare
Apparently I can cut and paste |
2b05b8a
to
4e10b12
Compare
/assign @lionelvillard |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if intended, but while heartbeats
manifest has been updated with resources/security, appender
and event_display
has not. recordevents
(not sure if that's generally considered a tool people could use or an internal testing tool only) also lacks them.
I thought that heartbeats was related to one of the GA components, while recordeevents and appender did not seem to be documented on knative.dev. |
/assign I will take a look at this |
/hold |
readOnlyRootFilesystem: true | ||
runAsNonRoot: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some of this was already done before and got reverted - see: https://github.com/knative/eventing/pull/5629/files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW we reverted because we didn't have time - at the time - to figure out mem/cpu requests that were low enough to work reliably in GitHub actions, the securityContext stuff should IMO be good either way, and I think having resources present - even if low - is better than not having them at all (so being entirely at the mercy of the scheduler happening not to collocate too many jobs on a node).
tl;dr imo we should just make sure this reliably works in GitHub actions, and lower mem/cpu until it does :)
hrm - getting that from |
requests: | ||
cpu: 100m | ||
memory: 100Mi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as said before, not sure we really have facts for bumping the numbers to this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fwiw I think any request is better than no request at all here, otherwise it really is just luck causing the controller to be on a node with any mem/cpu left at all iyswim
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These requests were copied from serving; I agree that they could probably be tuned (lower, I'm hoping), but leaving them out entirely doesn't do the scheduler any favors (and just pushes the issue to any responsible downstream distributors).
I agree that it would have been good if this had been in earlier in the release cycle; I forgot about it until 2 days ago.
Do you want me to split this into two ( |
I'm going to make this one be just Checking in now will give max time to bake for 1.1 |
I don't think that's this PR. /retest pull-knative-eventing-upgrade-tests |
@evankanderson: The
The following commands are available to trigger optional jobs:
Use In response to this:
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. |
/test pull-knative-eventing-upgrade-tests |
(This needs knative/hack#101 to pass) |
/test pull-knative-eventing-upgrade-tests |
(Tests now pass) |
Does making this just contain |
/unhold |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
(although I liked the resources version best, even if they were only a starting point to to get tuned later)
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: evankanderson, odacremolbap 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:
Approvers can indicate their approval by writing |
* adding/updating securityContext, as needed, to allow running as 'restricted' standard. * adding seccompProfile PR references from knative/eventing repo: * knative/eventing#5863 * knative/eventing#6533 Signed-off-by: Matthias Wessendorf <mwessend@redhat.com>
* adding/updating securityContext, as needed, to allow running as 'restricted' standard. * adding seccompProfile PR references from knative/eventing repo: * knative/eventing#5863 * knative/eventing#6533 Signed-off-by: Matthias Wessendorf <mwessend@redhat.com>
* adding/updating securityContext, as needed, to allow running as 'restricted' standard. * adding seccompProfile PR references from knative/eventing repo: * knative/eventing#5863 * knative/eventing#6533 Signed-off-by: Matthias Wessendorf <mwessend@redhat.com>
* adding/updating securityContext, as needed, to allow running as 'restricted' standard. * adding seccompProfile PR references from knative/eventing repo: * knative/eventing#5863 * knative/eventing#6533 Signed-off-by: Matthias Wessendorf <mwessend@redhat.com>
* 🛂 Addressing PodSecurity violation warnings: * adding/updating securityContext, as needed, to allow running as 'restricted' standard. * adding seccompProfile PR references from knative/eventing repo: * knative/eventing#5863 * knative/eventing#6533 Signed-off-by: Matthias Wessendorf <mwessend@redhat.com> * revert zipkin changes Signed-off-by: Matthias Wessendorf <mwessend@redhat.com> * Update control-plane/config/post-install/500-storage-version-migrator.yaml Co-authored-by: Pierangelo Di Pilato <pierangelodipilato@gmail.com> Signed-off-by: Matthias Wessendorf <mwessend@redhat.com> Co-authored-by: Pierangelo Di Pilato <pierangelodipilato@gmail.com>
* adding/updating securityContext, as needed, to allow running as 'restricted' standard. * adding seccompProfile PR references from knative/eventing repo: * knative/eventing#5863 * knative/eventing#6533 Signed-off-by: Matthias Wessendorf <mwessend@redhat.com>
* passport_control: Addressing PodSecurity violation warnings: * adding/updating securityContext, as needed, to allow running as 'restricted' standard. * adding seccompProfile PR references from knative/eventing repo: * knative/eventing#5863 * knative/eventing#6533 Signed-off-by: Matthias Wessendorf <mwessend@redhat.com> * revert zipkin changes Signed-off-by: Matthias Wessendorf <mwessend@redhat.com> * Update control-plane/config/post-install/500-storage-version-migrator.yaml Co-authored-by: Pierangelo Di Pilato <pierangelodipilato@gmail.com> Signed-off-by: Matthias Wessendorf <mwessend@redhat.com> Co-authored-by: Matthias Wessendorf <mwessend@redhat.com> Co-authored-by: Pierangelo Di Pilato <pierangelodipilato@gmail.com>
Proposed Changes
restricted
Pod Security StandardPre-review Checklist
Release Note
Docs
No docs impact