PodSecurityPolicy deprecated in Kubernetes 1.21

[pietervincken]

Expected Behavior

The released deployment manifest doesn't have deprecated resources listed in it.

Actual Behavior

PodSecurityPolicy tekton-pipelines is listed in the deployment manifest which is a deprecated resource as of 1.21.

Steps to Reproduce the Problem

1. Download the latest release yaml (tested with 0.26.0)

Additional Info

• Kubernetes version: 1.21

  Output of kubectl version:
  N/A

• Tekton Pipeline version:

0.26.0

[vdemeester]

@pietervincken thanks for the issue. Indeed, I think we should just remove this from the config folder (and thus from the released yamls).

/cc @tektoncd/core-maintainers

[dibyom]

Some background reading: https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/

[afrittoli]

@vdemeester I will move this to the next milestone. Let me know if there is any concern.

[ghost]

Looks like the replacement feature in Kubernetes will be called "PodSecurity Admission". Released as alpha in 1.22

[lbernick]

/priority important-soon

[afrittoli]

Discussed during the Pipeline WG:

• we shall had support for the new mechanism but keep PSP in parallel
• both methods can stay together until Pod Security Admission is stable

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
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 with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[nanoq66]

/remove-lifecycle stale
still relevant IMHO k8s 1.25 is getting closer ;)

[vdemeester]

If PodSecurityPolicy are removed in 1.25, then we need to either remove it for 0.36 or 0.37 (any release that would be in the 1.25 timeframe more or less) or be able to generate release with and without it.
I can re-open #4122 if need be.

[dibyom]

I think we need to do this soon - we could point users to https://appvia.github.io/psp-migration/ to migrate to an alternate policy engine. We could also see if we can enable https://kubernetes.io/docs/concepts/security/pod-security-admission/

[abayer]

Resurrecting this again - looks like PodSecurityPolicy has been removed in k8s 1.25, so we need to push this. I'm putting this in the v0.39 milestone, but am going to assume it'll end up slipping to v0.40 just due to time.

[abayer]

/priority critical-urgent

Actually, I just put it in v0.40, but am also bumping the priority.

[pritidesai]

@jerop to find someone who can help with this!

[pritidesai]

The replacement is beta which is reasonable to replace with

[JeromeJu]

/assign

[JeromeJu]

Drafted the doc WIP for PSP migration.

According to the references in the doc, here are the aspects according to current PSP that PSA might not cover:

• The seLinux config requires the privileged level in PSA, which might be different from our privileged setting in PSP.
• The supplementalGroups/ fsGroup rules are set as a range with mustRunAs rule in PSP but not specified in PSA.

[JeromeJu]

I think we should go for the 1st option in the doc of using PSA with OPA as complement for some of the specifications eg. seLinux supplementalGroup fsGroup as the other two options would both introduce more dependencies that we don’t want.

Would appreciate it if people could take a look at this doc and help with some opinions!

[dibyom]

From Pipelines WG:

1. Remove PSP
2. Add a PSA to do as much as the existing PSP can
3. Document how to achieve the same behavior with an alternative (OPA or another policy)