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
PodSecurity admission (PodSecurityPolicy replacement) #2579
Comments
Hi @tallclair This enhancement is in good shape for 1.22, a couple minor change requests in light of Enhancement Freeze on Thursday May 13th:
Thank you! |
|
Hi there, thanks for the speedy updates.
|
Hi @tallclair |
yes, this is one of the top three items sig-auth is tackling this release |
Hello @tallclair This enhancement is marked as Needs Docs for 1.22 release. Thank you! |
Hi @tallclair In light of Code Freeze on July 8th, this enhancement current status is Thanks |
kubernetes/kubernetes#103099 is open for this enhancement |
all code PRs are merged for beta, beta docs PR for 1.23 open at kubernetes/website#30351 |
I am currently checking the PodSecurity alpha version and one question comes to my mind. I am using |
Obviously, I think it's option 2 |
Why does node-exporter daemonset need privileged?It's just get metrics . |
@rensx5514 it collects metrics data from the node itself, manifest https://gist.github.com/zetaab/cae34a02d474ae98644ffa23b0815039 when trying to
|
I think maybe you can move node-exporter to kube-system. Otherwise, you might need to put it in a separate namespace. |
@zetaab @rensx5514 yes, the granularity of the PodSecurity feature is at the namespace level, so the namespace enforcement level must be the upper bound. Workload authors within the namespace can choose not to make use of all the allowed permissions, so you could certainly run a baseline- or restricted-compatible workload in a privileged namespace. (as an aside, this issue is primarily meant as a tracking issue for the feature status... for questions or discussion about the feature, I'd recommend the sig-auth slack channel / mailing list / or bi-weekly meeting) |
plan is to continue beta work for 1.24 and target GA in 1.25 |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
Can we try our best to make sure kubernetes/kubernetes#105919 lands in 1.25 too? We are pursuing having 'PodOS' field go to GA in 1.25 too and without this change users may be unable to schedule Windows pods that specify a For example: |
yes, I'd expect kubernetes/kubernetes#105919 to be required for GA of the PodOS feature |
Yes, that is the goal and this was the PR I mentioned during sig-windows community meeting on Tuesday. We also explicitly mentioned it in KEP
|
Enhancement Description
One-line enhancement description (can be used as a release note): Introduce a new admission controller for enforcing the Pod Security Standards on pods in a namespace.
Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/2579-psp-replacement/
Discussion Link: https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#bookmark=id.km06bp3uzuco
Primary contact (assignee): @tallclair
Responsible SIGs: sig-auth, sig-security
Enhancement target (which target equals to which milestone):
Alpha (1.22)
k/enhancements
) update PR(s): #2582k/k
) update PR(s):k/website
) update PR(s):Beta (1.23)
k/enhancements
) update PR(s):k/k
) update PR(s):k/website
) update(s):Stable (1.25)
k/enhancements
) update PR(s): #3310k/k
) update PR(s):k/website
) update(s):The text was updated successfully, but these errors were encountered: