[Deprecated] PodSecurityPolicy

[JeromeJu]

Changes

This commit removes the deprecated PodSeucrityPolicy and provide a guide moving forward for users.

Fixes: https://github.com/tektoncd/pipeline/issues/4112 /kind bug

TODO: Apply PSA & OPA that could cover what previously PSP has achieved.

Submitter Checklist

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

• [x] Has Docs included if any changes are user facing
• [n/a] Has Tests included if any functionality added or changed
• [x] Follows the commit message standard
• [x] Meets the Tekton contributor standards (including functionality, content, code)
• [x] Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• [x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
• [x] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

PodSecurityPolicy is deprecated.

[tekton-robot]

Skipping CI for Draft Pull Request. If you want CI signal for your change, please convert it to an actual PR. You can still manually trigger a test run with /test all

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: To complete the pull request process, please assign dibyom after the PR has been reviewed. You can assign the PR to them by writing /assign @dibyom in a comment when ready.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[JeromeJu]

How are we going to test the PSA implementation against PSP?

[dibyom]

How are we going to test the PSA implementation against PSP?

I'm not sure if I fully understand the question but from reading your doc, it looks like we'd have to use PSA level "privileged" . You also provide the 3 policies that one would have to implement using an external policy engine like OPA. I think that's sufficient

[JeromeJu]

How are we going to test the PSA implementation against PSP?

I'm not sure if I fully understand the question but from reading your doc, it looks like we'd have to use PSA level "privileged" . You also provide the 3 policies that one would have to implement using an external policy engine like OPA. I think that's sufficient

Yes, I would like to ask, as pointed in the WG, do we need to provide the implementation of a PSA controller as an example, which should be an equivalence of 101-podsecuritypolicy.yaml as we are currently removing from pipeline in this PR? If that is the case, do we need to have test cases that compares each specification between those two?

[JeromeJu]

Goal: When we remove psp, the security specs should be the same for webhooks and controllers service account.

TODO:

• figure out restricted level of PSA applied to namespaces for the cluster operators.

• eg. put selinux option in controller config to be tested in integration.

• https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container

• if restricted not covering PSP (not necessarily PSP but actually what the webhook and the controller needs), then we might need instructions for cluster operators to enforce restrictions eg. OPA

• check if integration test could pass to tell if the correct security access has been granted

• figure out the authencations #L22 in 101-psp.yaml (https://kubernetes.io/docs/tutorials/security/apparmor/)

PSP specs reference: https://unofficial-kubernetes.readthedocs.io/en/latest/concepts/policy/pod-security-policy/ https://v1-21.docs.kubernetes.io/docs/concepts/policy/pod-security-policy/