PSP: Rename restricted to zz-minimal

[surajssd]

• This PR renames the PSP restricted to zz-minimal, so that it is the last one in the list of PSPs but before the privileged PSP. restricted is applicable to all the workloads in the cluster. If a component already ships a PSP then that specific PSP should be the one that is applied to the workload, not the restricted PSP. So keeping it last in the list makes sure that pod is not filtered under restricted PSP. This was discovered when restricted PSP was interfering with the rook PSP.

• This PR renames the PSP privileged to zz-privileged. This is done in order to avoid the situation where privileged PSP is picked up accidently even though a specific, small scoped (in terms of permissions) PSP exists.

• openebs: Rename PSP usage. Use policy zz-privileged and not privileged.

[invidian]

Wait, now that I think about it, shouldn't privileged be renamed to zz-privileged, so it is being picked up as a last effort?

[iaguis]

CI is failing, can you retrigger?

[surajssd]

I have a hunch that openebs fails and am currently testing this issue locally.

[invidian]

@surajssd shouldn't restricted be named aa-restricted or something? So if it's compatible with with some pod, it will be used?

[surajssd]

@surajssd shouldn't restricted be named aa-restricted or something? So if it's compatible with with some pod, it will be used?

No, it will cause problems. So right now any workload in the cluster has at least one policy that it can go through i.e. restricted PSP. And it happens because we have this binding here:

lokomotive/assets/lokomotive-kubernetes/bootkube/resources/charts/kubernetes/templates/psp-restricted.yaml

Lines 60 to 72 in 9bd75f0

	---
	kind: ClusterRoleBinding
	apiVersion: rbac.authorization.k8s.io/v1
	metadata:
	name: restricted-psp-system-authenticated
	roleRef:
	kind: ClusterRole
	name: restricted-psp
	apiGroup: rbac.authorization.k8s.io
	subjects:
	- kind: Group
	name: system:authenticated
	apiGroup: rbac.authorization.k8s.io

Now imagine a workload which has it's own PSP. Now that workload is eligible for two PSPs one is its own and another is restricted one. Now the problem here is if restricted PSP takes precedence(in alphabetical order) for the application then that workload might not work reliably. Because the PSP that was shipped with the component is not applied but restricted PSP is applied, which greatly hinders what an app in the pod can do.

So there are two ways to solve this problem either we remove the aforementioned binding:

lokomotive/assets/lokomotive-kubernetes/bootkube/resources/charts/kubernetes/templates/psp-restricted.yaml

Lines 69 to 72 in 9bd75f0

	subjects:
	- kind: Group
	name: system:authenticated
	apiGroup: rbac.authorization.k8s.io

By removing this binding we withdraw the ability of an application workload to work out of the box in Lokomotive, especially those that don't ship PSP. So we will have to create Rolebinding as needed. That is provide restricted PSP on a case by case basis. Like someone has to create a Rolebinding when they create a new namespace as follows:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: restricted-psp-mywebapp
  namespace: mywebapp
roleRef:
  kind: ClusterRole
  name: restricted-psp
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: default
  namespace: mywebapp

OR we solve the problem by making sure the ordering is correct in the PSP names like it is done in this PR.

---

Now we have to make a choice to be specific a trade off between usability and security here.

[invidian]

I got one more idea.

[invidian]

Maybe we could name it to zz-minimal, so then it goes before zz-privileged?