fix(k8s-rbac): update permission mapping between k8s and cryostat

[tthvo]

Fixes #979
Related to cryostatio/cryostat-operator#440

Use alternatives for mapping between k8s resource to cryostat since flightRecorder/Recordings are deprecated.

[tthvo]

Marked as draft to update tests and check with running cluster.

[tthvo]

Currently, this is my idea for refining the mappings:

# Access pods (i.e application) and establish connections (i.e. using service instead of endpoints)
TARGET=pods,services 
# Access Cryostat to operate (i.e. execute) recordings
RECORDING=pods,pods/exec,cryostats.operator.cryostat.io
# Mount certificates from secrets into Cryostat
CERTIFICATE=pods,secrets,cryostats.operator.cryostat.io 
# Access Cryostat to add credentials (i.e. via webUI I think)
CREDENTIALS=pods,cryostats.operator.cryostat.io 

Any thoughts @andrewazores @ebaron?

[ebaron]

Currently, this is my idea for refining the mappings:

# Access pods (i.e application) and establish connections (i.e. using service instead of endpoints)
TARGET=pods,services 
# Access Cryostat to operate (i.e. execute) recordings
RECORDING=pods,pods/exec,cryostats.operator.cryostat.io
# Mount certificates from secrets into Cryostat
CERTIFICATE=pods,secrets,cryostats.operator.cryostat.io 
# Access Cryostat to add credentials (i.e. via webUI I think)
CREDENTIALS=pods,cryostats.operator.cryostat.io 

Any thoughts @andrewazores @ebaron?

I think this is good. While the certificates themselves may not be sensitive, the act of telling Cryostat to trust them should be privileged. I would also add Secrets for credentials as well, since that is a common use case for Secrets in Kubernetes.

[tthvo]

@andrewazores I believe #625 is resolved since #1037? Just come across a FIXME to disable reading kubeconfig in OpenShiftAuthManagerTest.

[andrewazores]

@tthvo thanks: #1057

[tthvo]

@ebaron @andrewazores Ready for review :D

For tests, I just removed references in deprecated apis. There was no issue with subresource being used in tests (I thought it would be part of the getResource but using getSubResource is the right way).

[andrewazores]

LGTM

[ebaron]

Seems good to me. This should probably be committed close to cryostatio/cryostat-operator#440, otherwise the OAuth tokens will not have the correct set of permissions.

[tthvo]

Right, I will update cryostatio/cryostat-operator#440 oauth role with these default permissions and tests it.

[tthvo]

Since including Secrets in mapping is denied due escalation security issue, I am thinking of its "closely" resembling resource ConfigMap though I am not sure if it is good alternative.

See original cryostatio/cryostat-operator#440 (comment)

[ebaron]

Since including Secrets in mapping is denied due escalation security issue, I am thinking of its "closely" resembling resource ConfigMap though I am not sure if it is good alternative.

See original cryostatio/cryostat-operator#440 (comment)

Config Maps are similar, but not used for sensitive data, while Secrets are. I can't think of any other reasonable substitute though, so I'd say either use Config Maps or remove it entirely.

[tthvo]

Right, I would just remove secrets instead of adding ConfigMap as it could means unprotected data which is not the case for certificates and credentials.

[tthvo]

I found some ConfigMap that actually contains certificate data. I think in the case of certificates, we could use ConfigMap?

$ oc get cm
NAME                       DATA   AGE
auth-properties            1      24h
kube-root-ca.crt           1      65d
openshift-service-ca.crt   1      65d

Checking kube-root-ca.crt

$ oc get cm/kube-root-ca.crt -o json
{
    "apiVersion": "v1",
    "data": {
        "ca.crt": [...]
    },
    "kind": "ConfigMap",
    "metadata": {
        "annotations": {
            "kubernetes.io/description": "Contains a CA bundle that can be used to verify the kube-apiserver when using internal endpoints such as the internal service IP or kubernetes.default.svc. No other usage is guaranteed across distributions of Kubernetes clusters."
        },
        "creationTimestamp": "2022-08-25T15:24:24Z",
        "name": "kube-root-ca.crt",
        "namespace": "default",
        "resourceVersion": "17608",
        "uid": "6698a4f7-a1a3-431b-a8fb-89f2ac097313"
    }
}

[ebaron]

I found some ConfigMap that actually contains certificate data. I think in the case of certificates, we could use ConfigMap?

I don't think we gain much from doing that. Certificates can be stored in Config Maps because they aren't sensitive, but for Cryostat, the certificate permission allows the user to tell Cryostat to trust a certificate. This should be somewhat of a privileged action, and I don't think creating/updating config maps in the namespace captures it. Permission to create/update the Cryostat CR is better, because that captures more of an admin role.

[tthvo]

Oh right! Make sense! Thanks a lot for explaining! I will finish up features to add custom role on top of default and clean up tests before marking this ready,

[ebaron]

Thanks, once this is ready, I'll test this one along with the operator PR and we should (hopefully) be done.

[ebaron]

Works well for me!