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

Pod Security Policy #5

Open
erictune opened this issue May 9, 2016 · 61 comments

Comments

Projects
None yet
@erictune
Copy link
Member

commented May 9, 2016

Feature Description

Related issues

  • kubernetes/kubernetes#43214 - Move out of extensions/v1beta1 API group:
    • 1.10
      • additionally allow authorizing via use verb in policy API group (will need to allow via either group for some time period)
      • update e2e tests (test both for some time period)
    • 1.11
      • move internal types to policy package (cleanup)
      • move registry to policy package (cleanup)
      • update addon manifests to use policy/v1beta1, grant permissions in policy API group
      • switch admission plugin to use policy group informer
      • switch preferred storage version to policy group
  • kubernetes/kubernetes#56174
  • kubernetes/kubernetes#55435
  • kubernetes/kubernetes#56173
@erictune

This comment has been minimized.

Copy link
Member Author

commented May 9, 2016

Admission controller code is under review in: kubernetes/kubernetes#24600

@erictune

This comment has been minimized.

Copy link
Member Author

commented May 9, 2016

This feature is skipping straight to Beta since it has had initial exposure in OpenShift.

@erictune

This comment has been minimized.

Copy link
Member Author

commented May 9, 2016

It will be default disabled in kubernetes/kubernetes#24600. After that goes in, we need changes in the admission controller to link PSPs to users.

@pweil-

This comment has been minimized.

Copy link
Member

commented May 11, 2016

Noting kubernetes/kubernetes#20573 as a dependency for the next step on PSP (subject level access)

@bryk

This comment has been minimized.

Copy link

commented Jul 12, 2016

Whats the status of this? Is the description in first comment up to date?

@pweil-

This comment has been minimized.

Copy link
Member

commented Jul 12, 2016

Is the description in first comment up to date

no (I don't have permissions to update). I believe all of the alpha requirements have been met. The initial types, api, and tests have been merged. The admission controller is not enabled by default.

IMO the remaining work for beta/1.4 is auth integration for permissions, updating for new fields we want to constraint (seccomp - in progress, sysctl), and any required docs/tutorials.

@erictune

This comment has been minimized.

Copy link
Member Author

commented Jul 12, 2016

And an e2e test.

On Tue, Jul 12, 2016 at 6:23 AM, Paul Weil notifications@github.com wrote:

Is the description in first comment up to date

no (I don't have permissions to update). I believe all of the alpha
requirements have been met. The initial types, api, and tests have been
merged. The admission controller is not enabled by default.

IMO the remaining work for beta/1.4 is auth integration for permissions,
updating for new fields we want to constraint (seccomp - in progress,
sysctl), and any required docs/tutorials.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AHuudqFwephlYk0Y1PS77y0xxA5QW0_-ks5qU5U7gaJpZM4IaU8n
.

@therc

This comment has been minimized.

Copy link

commented Jul 15, 2016

How about interactions with cloud providers? It would be nice to easily assign each pod different IAM roles so they can access only the subset of cloud services that they actually need. Would it be in scope or is it considered a SecurityContext detail?

@erictune

This comment has been minimized.

Copy link
Member Author

commented Jul 16, 2016

@therc that should be done via ServiceAccount.

@idvoretskyi idvoretskyi modified the milestone: v1.4 Jul 18, 2016

@idvoretskyi idvoretskyi added the sig/node label Aug 4, 2016

@pweil-

This comment has been minimized.

Copy link
Member

commented Aug 22, 2016

@goltermann I noticed this was marked with alpha but I believe it probably needs the beta tag based on #5 (comment)

@goltermann

This comment has been minimized.

Copy link
Contributor

commented Aug 22, 2016

@erictune does beta sound right based on the @pweil- comment?

@pweil-

This comment has been minimized.

Copy link
Member

commented Aug 22, 2016

@goltermann I think technically this would've been beta in 1.3, it is not new to 1.4 though development is ongoing.

@erictune

This comment has been minimized.

Copy link
Member Author

commented Aug 22, 2016

Yes, beta is correct. I was incorrect when I said alpha earlier today.

@goltermann goltermann added beta-in-1.4 and removed alpha-in-1.4 labels Aug 22, 2016

@goltermann

This comment has been minimized.

Copy link
Contributor

commented Aug 22, 2016

great, fixed it up

@janetkuo

This comment has been minimized.

Copy link
Member

commented Sep 2, 2016

@pweil- Are the docs ready? Please update the docs to https://github.com/kubernetes/kubernetes.github.io, and then add PR numbers and have the docs box checked in the issue description

@pweil-

This comment has been minimized.

Copy link
Member

commented Sep 2, 2016

@janetkuo docs PR kubernetes/website#1150

edit: kubernetes/website#1206 is the correct 1.4 PR

cc @kubernetes/feature-reviewers

@idvoretskyi

This comment has been minimized.

Copy link
Member

commented Sep 21, 2016

@pweil- I suppose, this PR is actual - kubernetes/website#1206?

@pweil-

This comment has been minimized.

Copy link
Member

commented Sep 22, 2016

correct

@php-coder

This comment has been minimized.

Copy link

commented Aug 14, 2018

/unassign

@justaugustus

This comment has been minimized.

Copy link
Member

commented Aug 14, 2018

/assign @tallclair

@kacole2

This comment has been minimized.

Copy link
Member

commented Oct 8, 2018

Hi
This enhancement has been tracked before, so we'd like to check in and see if there are any plans for this to graduate stages in Kubernetes 1.13. This release is targeted to be more ‘stable’ and will have an aggressive timeline. Please only include this enhancement if there is a high level of confidence it will meet the following deadlines:

  • Docs (open placeholder PRs): 11/8
  • Code Slush: 11/9
  • Code Freeze Begins: 11/15
  • Docs Complete and Reviewed: 11/27

Please take a moment to update the milestones on your original post for future tracking and ping @kacole2 if it needs to be included in the 1.13 Enhancements Tracking Sheet

Thanks!

@tallclair

This comment has been minimized.

Copy link
Member

commented Oct 8, 2018

No changes planned in 1.13.

@fejta-bot

This comment has been minimized.

Copy link

commented Jan 6, 2019

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@krmayankk

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2019

/remove-lifecycle stale

@claurence

This comment has been minimized.

Copy link

commented Jan 16, 2019

@tallclair Hello - I’m the enhancement’s lead for 1.14 and I’m checking in on this issue to see what work (if any) is being planned for the 1.14 release. Enhancements freeze is Jan 29th and I want to remind that all enhancements must have a KEP

@tallclair

This comment has been minimized.

Copy link
Member

commented Jan 16, 2019

Nothing planned for 1.14.

@zhouhaibing089

This comment has been minimized.

Copy link

commented Mar 25, 2019

What are the gaps for this to be GA? I can think about few, but I do not see any criteria in the description.

@tallclair

This comment has been minimized.

Copy link
Member

commented Mar 25, 2019

Before this can go to GA, we need to fix these problems:

  1. Flawed authorization model - PSP usage is granted through RBAC, and can either be granted to the user, or the created pod. Granting it to the user is the intuitive approach, but is problematic (see explanation). This approach also has some security issues.
  2. Difficult to roll out - Because pods are rejected by default, we cannot roll out PSP to all clusters without breaking them. Similarly, users who would like to enable PSP need to ensure complete coverage of all workloads before they can turn it on, which makes it difficult to enable (hence the relatively low usage). Because the feature must be explicitly enabled, we do not have adequate test coverage (the feature matrix is too complex).
  3. Inconsistent API - Less of a fundamental issue, but evolution of the PSP API over a long span of k8s releases has led to a number of inconsistencies making it difficult to use. In particular, mutation is lumped together with validation, which can lead to some unexpected results when a pod has access to multiple PSPs.

@liggitt and I have some ideas about how to address this, but there's an open question about whether this belongs in core Kubernetes. I'd like to have a roadmap out in the next month, either a plan for going to GA or a plan for deprecation.

@zhouhaibing089

This comment has been minimized.

Copy link

commented Mar 25, 2019

Thanks for sharing the information!

Because pods are rejected by default, we cannot roll out PSP to all clusters without breaking them.

I guess it is not really that. We did this by creating a PodSecurityPolicy which is open enough(or even open all) firstly, and then refine that gradually.

@tallclair

This comment has been minimized.

Copy link
Member

commented Mar 26, 2019

@zhouhaibing089 a Kubrenetes user can use that method which works because they control the policies. However, we cannot roll that out as a Kubernetes default since PodSecurityPolicy only opens the cluster up, meaning it's very difficult to manage the system controlled allow-all PSP.

@kacole2

This comment has been minimized.

Copy link
Member

commented Apr 12, 2019

Hello @liggitt @tallclair , I'm the Enhancement Lead for 1.15. Is this feature going to be graduating alpha/beta/stable stages in 1.15? Please let me know so it can be tracked properly and added to the spreadsheet. The community proposal will need to be migrated to a KEP for inclusion in 1.15.

Once coding begins, please list all relevant k/k PRs in this issue so they can be tracked properly.

@tallclair

This comment has been minimized.

Copy link
Member

commented Apr 12, 2019

No changes planned for 1.15

@lachie83

This comment has been minimized.

Copy link
Member

commented Jun 19, 2019

@tallclair Would really love to see this land as GA in 1.16. Is that possible?

@tallclair

This comment has been minimized.

Copy link
Member

commented Jun 19, 2019

@lachie83 No, we're not sure we want PodSecurityPolicy to go to GA. It's not clear that this is a use case that should be solved by Kubernetes core, and we're looking into out-of-core alternatives. If you'd like to discuss it in more detail, it's a good topic for SIG-Auth.

@SEJeff

This comment has been minimized.

Copy link

commented Jun 19, 2019

@tallclair Would stuff like Open Policy Agent's gatekeeper be a better path to head down?

@tallclair

This comment has been minimized.

Copy link
Member

commented Jun 19, 2019

Yes, exactly. That might be the leading contender, and I'm working closely with that team to see make sure it will cover these use cases.

@SEJeff

This comment has been minimized.

Copy link

commented Jun 19, 2019

The one thing I've been waiting for, is a tool that could potentially translate PodSecurityPolicy --> OPA rego policy. That would make deprecating them from your standpoint a lot easier.

@lachie83

This comment has been minimized.

Copy link
Member

commented Jun 19, 2019

@tallclair appreciate the prompt response

@tallclair

This comment has been minimized.

Copy link
Member

commented Jun 19, 2019

@SEJeff agreed. We will not deprecate PodSecurityPolicy until there is a clear replacement with feature parity and migration path.

@justaugustus

This comment has been minimized.

Copy link
Member

commented Jun 19, 2019

Hey @tallclair, you mentioned a roadmap to GA or a plan for deprecation. Seems like we're leaning towards the latter.

Do we have something written to help people that are looking at PSPs as a solution close the loop?

@tallclair

This comment has been minimized.

Copy link
Member

commented Jun 19, 2019

Not yet. Part of the hesitation is that we don't want to say that we'll be deprecating it in favor of something else until there is a clear replacement. Although I'm excited about gatekeeper, it doesn't have the features (or stability) we need to replace PSP yet. Another possibility is that we could move PSP out of tree, and bring it to GA as an admission webhook (the 2 options aren't mutually exclusive). We haven't formally laid out a roadmap yet though.

@angelbarrera92

This comment has been minimized.

Copy link

commented Jul 4, 2019

Wtf

@kacole2

This comment has been minimized.

Copy link
Member

commented Jul 9, 2019

Hi @tallclair looks like nothing is happening here for 1.16 as well so I'll keep it the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.