Skip to content
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

Open
8 of 12 tasks
tallclair opened this issue Mar 19, 2021 · 28 comments
Open
8 of 12 tasks

PodSecurity admission (PodSecurityPolicy replacement) #2579

tallclair opened this issue Mar 19, 2021 · 28 comments
Assignees
Labels
sig/auth sig/security stage/stable tracked/no
Milestone

Comments

@tallclair
Copy link
Member

@tallclair tallclair commented Mar 19, 2021

Enhancement Description

@tallclair tallclair added sig/auth sig/security labels Mar 19, 2021
@tallclair tallclair added this to the v1.22 milestone Mar 19, 2021
@tallclair tallclair mentioned this issue Mar 22, 2021
18 tasks
@tallclair tallclair changed the title Pod Isolation Policy (Pod Security Policy replacement) Pod Security Policy replacement Mar 30, 2021
@ritazh ritazh added this to KEP Backlog in SIG Auth Apr 9, 2021
@liggitt liggitt moved this from KEP Backlog to Backlog (v1.22) in SIG Auth Apr 16, 2021
@liggitt liggitt moved this from Backlog (v1.22) to KEP Backlog in SIG Auth Apr 16, 2021
@liggitt liggitt added the stage/alpha label Apr 29, 2021
@liggitt liggitt moved this from KEP Backlog to In Progress (v1.22) in SIG Auth Apr 29, 2021
@liggitt liggitt moved this from In Progress (v1.22) to In Review (v1.22) in SIG Auth Apr 29, 2021
@liggitt liggitt moved this from In Review (v1.22) to In Progress (v1.22) in SIG Auth Apr 29, 2021
@JamesLaverack JamesLaverack added the tracked/yes label Apr 29, 2021
@gracenng
Copy link
Member

@gracenng gracenng commented May 9, 2021

Hi @tallclair 👋 1.22 Enhancements shadow here.

This enhancement is in good shape for 1.22, a couple minor change requests in light of Enhancement Freeze on Thursday May 13th:

  • KEP has not been merged to master
  • the "reviewers" section in kep.yaml is not filled out
  • <<[unresolved]>> in README
  • Graduation Criteria in README

Thank you!

@tallclair
Copy link
Member Author

@tallclair tallclair commented May 10, 2021

  • I'm nagging the approvers daily, and still expect to get this merged by enhancement freeze
  • Filled in reviewers
  • The only remaining unresolved sections are explicitly flagged as non-blocking for the alpha. Is it OK to leave these sections for beta, or will they cause tooling issues?
  • Filled in graduation criteria

@gracenng
Copy link
Member

@gracenng gracenng commented May 10, 2021

Hi there, thanks for the speedy updates.

  • I talked to the team and it is okay to have unresolved sections for alpha
  • With regards to graduation criteria, the KEP template has been updated to clarify this. Apologies for the confusion.

@gracenng
Copy link
Member

@gracenng gracenng commented May 11, 2021

Hi @tallclair 👋 1.22 Enhancements shadow here.
I just wanted to double check to see if SIG-Auth will need to do anything for this enhancement and if so, are they OK with it?
Thanks!

@liggitt
Copy link
Member

@liggitt liggitt commented May 11, 2021

yes, this is one of the top three items sig-auth is tackling this release

@liggitt liggitt changed the title Pod Security Policy replacement PodSecurity admission (PodSecurityPolicy replacement) May 12, 2021
@ritpanjw
Copy link

@ritpanjw ritpanjw commented May 19, 2021

Hello @tallclair 👋 , 1.22 Docs Shadow here.

This enhancement is marked as Needs Docs for 1.22 release.
Please follow the steps detailed in the documentation to open a PR against dev-1.22 branch in the k/website repo. This PR can be just a placeholder at this time and must be created before Fri July 9, 11:59 PM PDT.
Also, take a look at Documenting for a release to familiarize yourself with the docs requirement for the release.

Thank you!

@gracenng
Copy link
Member

@gracenng gracenng commented Jun 23, 2021

Hi @tallclair 🌞 1.22 enhancements shadow here.

In light of Code Freeze on July 8th, this enhancement current status is at risk as there is no k/k PR tracked.
Please update the associated PR or let me know if there is none required for this enhancement.

Thanks

@liggitt
Copy link
Member

@liggitt liggitt commented Jun 23, 2021

kubernetes/kubernetes#103099 is open for this enhancement

@liggitt
Copy link
Member

@liggitt liggitt commented Nov 3, 2021

all code PRs are merged for beta, beta docs PR for 1.23 open at kubernetes/website#30351

@zetaab
Copy link
Member

@zetaab zetaab commented Dec 14, 2021

I am currently checking the PodSecurity alpha version and one question comes to my mind. I am using kube-prometheus (https://github.com/prometheus-operator/kube-prometheus) to monitor my cluster. When I execute kubectl label --dry-run=server --overwrite ns --all pod-security.kubernetes.io/enforce=restricted or kubectl label --dry-run=server --overwrite ns --all pod-security.kubernetes.io/enforce=baseline. I can see that node-exporter daemonset needs privileged mode. However, none of the other components needs that. With current design it is not possible to add different policy to single daemonset/deployment/sts? Only option is either 1) allow all pods to use privileged (imo not great option) in monitoring namespace 2) move node-exporter daemonset to another namespace that has privileged access. Which one we should choose in future?

@rensx5514
Copy link

@rensx5514 rensx5514 commented Dec 14, 2021

I am currently checking the PodSecurity alpha version and one question comes to my mind. I am using kube-prometheus (https://github.com/prometheus-operator/kube-prometheus) to monitor my cluster. When I execute kubectl label --dry-run=server --overwrite ns --all pod-security.kubernetes.io/enforce=restricted or kubectl label --dry-run=server --overwrite ns --all pod-security.kubernetes.io/enforce=baseline. I can see that node-exporter daemonset needs privileged mode. However, none of the other components needs that. With current design it is not possible to add different policy to single daemonset/deployment/sts? Only option is either 1) allow all pods to use privileged (imo not great option) in monitoring namespace 2) move node-exporter daemonset to another namespace that has privileged access. Which one we should choose in future?

Obviously, I think it's option 2

@rensx5514
Copy link

@rensx5514 rensx5514 commented Dec 14, 2021

I am currently checking the PodSecurity alpha version and one question comes to my mind. I am using kube-prometheus (https://github.com/prometheus-operator/kube-prometheus) to monitor my cluster. When I execute kubectl label --dry-run=server --overwrite ns --all pod-security.kubernetes.io/enforce=restricted or kubectl label --dry-run=server --overwrite ns --all pod-security.kubernetes.io/enforce=baseline. I can see that node-exporter daemonset needs privileged mode. However, none of the other components needs that. With current design it is not possible to add different policy to single daemonset/deployment/sts? Only option is either 1) allow all pods to use privileged (imo not great option) in monitoring namespace 2) move node-exporter daemonset to another namespace that has privileged access. Which one we should choose in future?

Why does node-exporter daemonset need privileged?It's just get metrics .

@zetaab
Copy link
Member

@zetaab zetaab commented Dec 14, 2021

@rensx5514 it collects metrics data from the node itself, manifest https://gist.github.com/zetaab/cae34a02d474ae98644ffa23b0815039

when trying to restricted policy to it:

Warning: node-exporter-v9zm9: host namespaces, hostPath volumes, hostPort, restricted volume types
Warning: node-exporter-64x4b: host namespaces, hostPath volumes, hostPort, restricted volume types
Warning: node-exporter-ffkw9: host namespaces, hostPath volumes, hostPort, restricted volume types
Warning: node-exporter-7ldf6: host namespaces, hostPath volumes, hostPort, restricted volume types
Warning: node-exporter-6fmbm: host namespaces, hostPath volumes, hostPort, restricted volume types
Warning: node-exporter-dxb5v: host namespaces, hostPath volumes, hostPort, restricted volume types

@rensx5514
Copy link

@rensx5514 rensx5514 commented Dec 14, 2021

@rensx5514 it collects metrics data from the node itself, manifest https://gist.github.com/zetaab/cae34a02d474ae98644ffa23b0815039

when trying to restricted policy to it:

Warning: node-exporter-v9zm9: host namespaces, hostPath volumes, hostPort, restricted volume types
Warning: node-exporter-64x4b: host namespaces, hostPath volumes, hostPort, restricted volume types
Warning: node-exporter-ffkw9: host namespaces, hostPath volumes, hostPort, restricted volume types
Warning: node-exporter-7ldf6: host namespaces, hostPath volumes, hostPort, restricted volume types
Warning: node-exporter-6fmbm: host namespaces, hostPath volumes, hostPort, restricted volume types
Warning: node-exporter-dxb5v: host namespaces, hostPath volumes, hostPort, restricted volume types

I think maybe you can move node-exporter to kube-system. Otherwise, you might need to put it in a separate namespace.

@liggitt
Copy link
Member

@liggitt liggitt commented Dec 14, 2021

@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)

@gracenng gracenng removed this from the v1.23 milestone Jan 9, 2022
@gracenng gracenng added tracked/no and removed tracked/yes labels Jan 9, 2022
@liggitt liggitt added this to the v1.24 milestone Jan 18, 2022
@liggitt
Copy link
Member

@liggitt liggitt commented Jan 19, 2022

plan is to continue beta work for 1.24 and target GA in 1.25

@k8s-triage-robot
Copy link

@k8s-triage-robot k8s-triage-robot commented Apr 19, 2022

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:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue or PR as fresh with /remove-lifecycle stale
  • Mark this issue or PR as rotten with /lifecycle rotten
  • Close this issue or PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale label Apr 19, 2022
@tallclair
Copy link
Member Author

@tallclair tallclair commented Apr 20, 2022

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale label Apr 20, 2022
@liggitt liggitt added stage/stable and removed stage/beta labels Apr 28, 2022
@marosset
Copy link
Contributor

@marosset marosset commented May 11, 2022

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 OS=windows with restricted policies.

For example:
Restricted policy enforces that ALL capabilities must be dropped for containers but pods that set OS=windows will be rejected if the specify anything in the capabilities fields.

@ravisantoshgudimetla FYI

@liggitt
Copy link
Member

@liggitt liggitt commented May 11, 2022

yes, I'd expect kubernetes/kubernetes#105919 to be required for GA of the PodOS feature

@ravisantoshgudimetla
Copy link
Contributor

@ravisantoshgudimetla ravisantoshgudimetla commented May 11, 2022

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 OS=windows with restricted policies.

For example: Restricted policy enforces that ALL capabilities must be dropped for containers but pods that set OS=windows will be rejected if the specify anything in the capabilities fields.

@ravisantoshgudimetla FYI

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

Pod Security Standards are to be changed in 1.25 timeframe to accommodate the supported kubelet and kube-apiserver skew.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/auth sig/security stage/stable tracked/no
Projects
SIG Auth
In Progress
Development

No branches or pull requests