[Task] Select default permissions that do not use FlightRecorder/Recording

[ebaron]

After #635, we can modify which Cryostat permissions map to which Kubernetes RBAC permissions. Now we should modify the default Kubernetes permissions from their current values. Since the FlightRecorder and Recordings APIs will soon be removed, we have to pick some alternatives. Ideally these would not depend on CRDs shipped with the operator, but that's not a hard requirement, it would simply allow for more flexibility.

[andrewazores]

It's also possible that the downstream build carries a patch for Operator-supplied CRDs. Or maybe the upstream Operator can even carry its own whole .properties file and mount that to the Cryostat container in place of the default upstream one.

[tthvo]

After reading through the OAuth setup,

https://github.com/cryostatio/cryostat/blob/74671b8b69174975d478ea83d79e8f895710e64b/src/main/resources/io/cryostat/net/openshift/OpenShiftAuthManager.properties#L11

For TARGET, I think it mostly needs permissions for pods, deployments.

https://github.com/cryostatio/cryostat/blob/74671b8b69174975d478ea83d79e8f895710e64b/src/main/resources/io/cryostat/net/openshift/OpenShiftAuthManager.properties#L12

For RECORDING, it is not easy to choose a mapping but I guess we could just have it as cryostats.operator.cryostat.io similar to CREDENTIAL since they are created, stored and accessed in somehow similar fashion.

Not sure I worded it right. Any thoughts @ebaron @andrewazores?

[ebaron]

I feel like the pod/exec subresource captures what we're doing here with recordings. The create pod/exec permission allows you to run arbitrary commands in the pod using kubectl exec.