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
[PSA] default warn to enforce level #113491
Conversation
@tallclair: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
/priority important-soon LGTM - will leave |
staging/src/k8s.io/pod-security-admission/admission/admission_test.go
Outdated
Show resolved
Hide resolved
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: liggitt, tallclair 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 |
/retest |
/skip |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Goal: in most cases, setting just the pod-security enforce level on a namespace should give warning on workload resource creation & update, rather than requiring both warn & enforce to be set.
When the pod-security enforce level is set, but the warn version is not set (and the default is less-restrictive), then default the warn level to the enforce level.
I wasn't sure exactly what the right behavior was for the version, so I went with this:
If only
enforce
andwarn-version
but notwarn
is set, shouldwarn
still be defaulted? I went with yes, but kept thewarn-version
.Special notes for your reviewer:
I think we've discussed this change in the past. The issue is that if a defaulting admission controller causes a workload to pass, then this could lead to erroneous warnings. This is not the common case, and can easily be bypassed by setting the
warn
level toprivileged
across all namespaces. I'd prefer to optimize for the common case here.Does this PR introduce a user-facing change?
/sig auth security
/milestone v1.26
/assign @liggitt