Remove PodSecurityPolicy ✂️

[vdemeester]

Changes

PodSecurityPolicy is being deprecated in Kubernetes 1.21, and isn't
being exercised by our CI. Let's just remove it from the payload (the
release.yaml file).

Closes #4112

Signed-off-by: Vincent Demeester [email protected]

/kind cleanup
/cc @tektoncd/core-collaborators

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Docs included if any changes are user facing
• Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including
  functionality, content, code)
• Release notes block below has been filled in or deleted (only if no user facing changes)

Release Notes

The PodSecurityPolicy shipped by Tekton is now removed as it is being deprecated in Kubernetes >= 1.21. See https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/ for more info

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbwsg

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [sbwsg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[afrittoli]

I don't see the rush for this TBH? Tekton min k8s version is 1.18, and PSP is not deprecated until 1.21.
We may have users that rely on the PSP in our release, and just removing it could break them.
We could al least give a few releases of notice?

Looking at https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/ a k8s replacement is not available yet, and PSP will still be available for a while. The alternative available today is admission controllers - so we could document that, or link to the k8s docs about that.

[afrittoli]

/test check-pr-has-kind-label

[vdemeester]

The corresponding issue is in 0.28 milestone, so I added it there.
@afrittoli do you think we should/could move this to 0.29 or 0.30 instead ? 🤔

[ghost]

We should probably figure out what user migration for this would look like - can we document the best next step as part of release notes? At the moment it's not totally clear what those steps would look like.

Maybe moving back to 0.30 is a good idea, and giving one release of notice for 0.29 that this is going away?

[jerop]

@tektoncd/core-maintainers, it seems we're not ready to move ahead with this so considering moving it to the next milestone - maybe we can give a deprecation notice for in this release as @sbwsg suggested above?

[dibyom]

maybe we can give a deprecation notice for in this release as @sbwsg suggested above?

Sounds good to me!

[dibyom]

/hold
based on discussions in the pipeline wg, we are figuring out how to migrate users to PodSecurityAdmission

[tekton-robot]

@vdemeester: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[HW-Owl]

@dibyom, we have also a strong interest to migrate to PodSecurityAdmission and are curious to see your solution.

Actually, we already tried some first steps. To achieve 'restricted' we just had to add 'runAsNonRoot = false' to 'securityContext' in various deployments.
Bigger problems are 'affinity-assistant' and 'eventlisteners', which are currently running with high privileges. We would be happy to see a solution where they could run in 'restricted' mode as default.

[vdemeester]

Closing this for the time being
/close

[tekton-robot]

@vdemeester: Closed this PR.

In response to this:

Closing this for the time being
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.