search

kubernetes / enhancements

Enhancements tracking repo for Kubernetes
Apache License 2.0
3.44k stars 1.48k forks source link

[Deprecated] Pod Security Policy #5

Closed erictune closed 2 years ago

erictune commented 8 years ago

Feature Description

Related issues

lachie83 commented 5 years ago

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

tallclair commented 5 years ago

@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 commented 5 years ago

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

tallclair commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@tallclair appreciate the prompt response

tallclair commented 5 years ago

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

justaugustus commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Wtf

kacole2 commented 5 years ago

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

mrbobbytables commented 5 years ago

Hey there @tallclair -- 1.17 Enhancement lead here -- it looks like this is staying as is for 1.17. If that changes, please don't hesitate to give me a poke and I can add it to the tracking sheet 👍

dstrebel commented 5 years ago

Has there been any more discussion on a clear path for the future of PSP?

JimBugwadia commented 5 years ago

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.

@tallclair - we have implemented most PSP checks in Kyverno. Can you help take a look? Would love to discuss ideas and details.

https://github.com/nirmata/kyverno/blob/master/samples/README.md

ritazh commented 5 years ago

The Gatekeeper project has also been looking at what a post-PSP world would look like. Our initial approach has been to break down the PSP resource into individual constraints. We were wondering what the community’s thoughts were on this approach. Maybe it would be a good time to re-imagine how these policies compose? Migration for both new users and existing PSP users will also be important.

cc @maxsmythe @sozercan @tsandall

tallclair commented 5 years ago

I have some concerns about breaking the policies into individual constraints, namely that I need to create many more constraint objects. If I think need to clone or alter those for different workloads, I'm worried it will become very complex.

I think the best approach would be a user-centric one. If we can get real feedback on how PSP's are being used, and then see what a similar setup would look like under these alternative plugins, then that can help shape the design.

JimBugwadia commented 5 years ago

@tallclair one of the use cases we are pursuing is related to namespace based multi-tenancy. The intent is to use policies to enforce restrictions and ensure that namespaces are properly configured.

jleadford commented 4 years ago

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.

@tallclair , I'm wondering about the above -- can you elaborate on how this approach is problematic and/or has security issues?

bjhaid commented 4 years ago

Can someone more informed please confirm this tweet:

https://twitter.com/TechJournalist/status/1197658440040165377

And if that's true, what should people using PSP to limit linux capabilities today do going forward?

yanniszark commented 4 years ago

Hi all, This is a very interesting discussion and we are currently looking for solutions to secure Pod creation in Kubernetes clusters.

We have taken a look at both OPA Gatekeeper and PodSecurityPolicies, as well as the effort to reimplement PSP in OPA constraints. The fundamental issue we found with this comparison is that we are dealing with two opposite models.

From a security perspective, I would argue that the PSP model is better, albeit more difficult to bring into existing clusters as all workloads must conform to it.

How do you plan to bridge this fundamental gap in architecture, between PSP and the Constraint Framework?

/cc @ritazh I'd love to hear your opinion on this, since you have worked on porting the PSP functionality to OPA.

tallclair commented 4 years ago

The different approaches definitely make migration more complicated. We're exploring different ways to make the transition smoother.

In a perfect world, I agree that deny-all-by-default is the more secure approach. However, it's one of the things that makes PSP so difficult to use and roll out. In practice, I think gradually ratcheting down permissions is more feasible, and as the old adage goes "the best security is the security you use".

On a side note, we're also discussing how to opt out / exclude / get exceptions to constraints (for example to protect the kube-system namespace). Depending on how this works, you could implement a deny-by-default approach by locking everything down, and then granting exceptions. I'm not sure if that's a use case we want to design for though...

johnbelamaric commented 4 years ago

@tallclair do you expect any progress on this in 1.18? I am an enhancements shadow for the release and would like to know if we should be tracking this.

tallclair commented 4 years ago

No changes planned for 1.18

fejta-bot commented 4 years ago

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

palnabarun commented 4 years ago

/remove-lifecycle stale

johnbelamaric commented 4 years ago

@tallclair Hi Tim. Any plans for this in 1.19?

tallclair commented 4 years ago

No plans for v1.19, although I'm hoping to see some movement in the v1.20 timeframe.

mhausenblas commented 4 years ago

Just stumbled upon Kubernetes Pod Security Policies with Open Policy Agent. @tallclair can you share what's blocking us and where help is needed, happy to contribute as well.

tallclair commented 4 years ago

can you share what's blocking us

Basically we just need to make a decision on a path forward. Currently, I think there is agreement that PSP should not go GA in its current form, but we haven't settled on a replacement yet. Options we've discussed:

  1. No replacement - recommend choosing from a third party option with an admission webhook. The recently published Pod security standards doc is trying to make this smoother by promoting equivalent functionality.
  2. Alterantive built in controls
    1. @deads2k has proposed upstreaming openshifts SecurityContextConstraints
    2. I've proposed a minimally configurable feature that only enforces the the standard policies linked above (and recommend a third party solution when more configurability is needed)
  3. Fix pod security policy - Although some of the issues are core enough to the design, that this would need to be non-backwards compatible, at which point it might as well be a new alternative in (2)
mlbiam commented 4 years ago

Am I reading https://github.com/kubernetes/kubernetes/pull/90603 correctly that because the pod security standards are published there's no planned replacement for PSPs in the API server and any replacement will need to be implemented as an outside system?

liggitt commented 4 years ago

See https://github.com/kubernetes/enhancements/issues/5#issuecomment-637066475

The deprecation schedule for the current beta version in 1.22 is independent of whether or not an in-tree implementation of the standard pod security profiles will be provided. That has not yet been determined.

mlbiam commented 4 years ago

Thanks @liggitt was confirming that nothing had been set. thought originally nothing would be deprecated until a replacement was available. Wasn't clear if a decision had been made one way or another.

liggitt commented 4 years ago

The deprecation timeline is not specific to PSP and was added as part of https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta

mlbiam commented 4 years ago

if i'm reading this correctly, whats pushing the deprecation is that no API should be in the same beta version for more then 9 months so PSP needs to get promoted or deprecated and since there won't be any new betas or GA of psp it needs to get on track for deprecation even though a replacement hasn't been decided on?

liggitt commented 4 years ago

if i'm reading this correctly, whats pushing the deprecation is that no API should be in the same beta version for more then 9 months

exactly. all future beta versions of all built in APIs will come with a prebaked deprecation and removal target when they are first introduced

kikisdeliveryservice commented 4 years ago

Hi @tallclair

Enhancements Lead here. Any plans for this in 1.20?

Thanks, Kirsten

tallclair commented 4 years ago

No plans for v1.20.

zapman449 commented 3 years ago

This situation is extremely frustrating for those of us needing to run high security clusters. Our options are:

  1. Sit and wait for PSPs to be deprecated.
  2. Outsource workload runtime security enforcement to a vendor (Styra), since OPA does not document how to run a fully restrictive PSP replacement with Rego.

So, my company has implemented fully locked down PSPs. They are not easy to implement, and debugging them is a chore, but they are highly functional, and they actually work. We even published a blog post detailing how they could be used this way, and how to handle exceptions when they happen.

IMO, the PSP beta should be merged as is into the mainline kubernetes core. My reasons are:

  1. While PSPs have flaws, they function, and have functioned for 10 releases.
  2. Kubernetes as a project should care about workload runtime security. Container escapes are far too easy. PSPs are one of the few tools which make this harder for attackers.
  3. Perfect is the enemy of Done. Merge PSPs as is, and push off the "better" implementation to policy/v2.
  4. Finally, and most important, it allows OSS developers to run higher security clusters, not just companies who can afford vendors like Styra.
maxsmythe commented 3 years ago

@zapman449 can you clarify what you mean by a "fully restrictive PSP replacement"?

Hopefully the Gatekeeper PSP library makes it easier to enforce rules similar to those used by PSP. I'm definitely interested in any functional gaps you are seeing.

christianhuening commented 3 years ago

@zapman449 would you happen to have a link to that blogpost?

zapman449 commented 3 years ago

@christianhuening https://developer.squareup.com/blog/kubernetes-pod-security-policies

zapman449 commented 3 years ago

@maxsmythe I haven't caught up on what Gatekeeper PSP is doing, will review.

However, what I mean is:

  1. Full control over process capabilities like NET_BIND_SERVICE, SYS_ADMIN, etc
  2. Restrict UID/GID/FSGroups to non-zero values
  3. Explicit listing of host paths which can be mounted
  4. Explicit listing of types of volume mounts allowed
  5. Block Privileged, block privilege escalation
  6. Block access to host level interprocess communication primitives
  7. Block access to host networking
  8. restrict which host ports are allowed
  9. Enforce readOnlyRootFilesystem
  10. Connection point for SELinux

These are provided today with PSPs.

If we're asking for a wishlist, I'd love:

  1. Smart defaults for SysCalls from containers. There's a small percentage of the total linux syscall list that most containers need. Let me restrict most containers to that list, then allow me to either explicitly allow certain calls for certain pods owned by certain service accounts, or to grant carte blanche to specific service accounts.
  2. Let me dream a bit more, and I'll come up with something. ;-)
tallclair commented 3 years ago

@zapman449 - If you haven't seen it, we discussed the future of PSPs in the last sig-auth meeting (https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#heading=h.hsgtsqg83z5u). We'll continue the discussion in the December 9th meeting if you're able to make it, but we also won't make any final decisions without a proposal being sent to the mailing list.

Our intention here is absolutely not to leave anyone high and dry. We know that PSPs address an important security need for Kubernetes, and the purpose of these discussions is to figure out what the best way to meet those needs in the future is.

coderanger commented 3 years ago

For anyone following this ticket, PSPs will be deprecated in 1.21 with removal targeted for 1.25.

deads2k commented 3 years ago

For anyone following this ticket, PSPs will be deprecated in 1.21 with removal targeted for 1.25.

This is correct. We moved deprecation from 1.22 to 1.21 because we know that existing PSP API will not be losslessly backward compatible with a future replacement. PSP removal is staying at the previously planned 1.25.

liggitt commented 3 years ago

next action is removal in 1.25

pierluigilenoci commented 3 years ago

@liggitt next action is PSP Replacement KEP

sftim commented 3 years ago

For more information on the deprecation, see PodSecurityPolicy Deprecation: Past, Present, and Future.

k8s-triage-robot commented 3 years ago

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

tallclair commented 3 years ago

/remove-lifecycle stale