-
Notifications
You must be signed in to change notification settings - Fork 64
🐛 (fix) PSA enforcement: Move from baseline to restricted #1829
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
🐛 (fix) PSA enforcement: Move from baseline to restricted #1829
Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
@@ -3,6 +3,6 @@ kind: Namespace | |||
metadata: | |||
labels: | |||
app.kubernetes.io/part-of: olm | |||
pod-security.kubernetes.io/enforce: baseline | |||
pod-security.kubernetes.io/enforce: restricted |
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.
@joelanford ^ JFY
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.
@camilamacedo86 can you identify which, if any, current e2e test might be able to verify this doesn't cause a problem? Maybe just?:
in ./kind-config.yaml
Should we turn on PodSecurity?
kubeadmConfigPatches:
- |
kind: ClusterConfiguration
apiServer:
extraArgs:
- enable-admission-plugins: OwnerReferencesPermissionEnforcement
+ enable-admission-plugins: OwnerReferencesPermissionEnforcement,PodSecurity
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.
e2e seems to pass for me with this set, so maybe it's all good?
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.
just trying to verify it's really used if I set it there
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.
When we install OLMv1 the ns will be set within right
So, the tests running on that. But do you still want any extra step? if so, can you please clarify? Sorry, I could not follow what are you asking for I do in this case.
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.
nvm, seems like at our current version enforced for Kind, we've got PodSecurity by default. Verified it bounced a non-compliant pod trying to be created in an NS set restricted. Since our current e2e do deployment, they must be okay.
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.
So, are you ok with this change as well? Right?
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1829 +/- ##
==========================================
- Coverage 68.44% 68.42% -0.02%
==========================================
Files 63 63
Lines 5134 5134
==========================================
- Hits 3514 3513 -1
- Misses 1390 1391 +1
Partials 230 230
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
7c10fb9
to
3e6fbbb
Compare
3e6fbbb
to
cfdb6ae
Compare
I need to rebase this one, |
Namespaces should be restricted by default rather than granted additional, unnecessary permissions.
cfdb6ae
to
f86d3f4
Compare
04a2b45
Namespaces should be restricted by default instead of have granted additional not required permissions
Description
Reviewer Checklist