inconsistency between access-matrix and "oc who-can"

[joyartoun]

Expected behavior
access-matrix should match with the command "oc who-can"

Actual behavior
access-matrix is not consistent with "oc who-can"

Steps To Reproduce
Steps to reproduce the behavior:
N/A

Context:
Rakess version:
rakkess: v0.5.0
platform: linux/amd64
git commit: e52bef1
build date: 2021-07-25T09:13:28Z
go version: go1.16.6
compiler: gc

oc client version:
oc version
Client Version: 4.11.0-0.okd-2022-08-20-022919
Kustomize Version: v4.5.4
Server Version: 4.11.0-0.okd-2022-08-20-022919
Kubernetes Version: v1.24.0-2368+b62823b40c2cb1-dirty

OKD version:
4.11.0-0.okd-2022-08-20-022919

kubectl version

Additional context
If I run the following command, you can see which groups and users can delete a secret in the namespace istio-system.

user@host: ~$ oc policy who-can delete secret
resourceaccessreviewresponse.authorization.openshift.io/<unknown>

Namespace: istio-system
Verb:      delete
Resource:  secrets

Users:  system:admin
        system:kube-controller-manager
        system:serviceaccount:argocd:argocd-argocd-application-controller
        system:serviceaccount:argocd:argocd-argocd-server
        system:serviceaccount:argocd:argocd-operator-controller-manager
        system:serviceaccount:argocd:openshift-gitops-applicationset-controller
        system:serviceaccount:argocd:openshift-gitops-argocd-application-controller
        system:serviceaccount:argocd:openshift-gitops-argocd-server
        system:serviceaccount:cert-manager:cert-manager
        system:serviceaccount:elastic-system:elastic-operator
        system:serviceaccount:istio-system:istiod
        system:serviceaccount:istio-system:istiod-service-account
        system:serviceaccount:kube-system:generic-garbage-collector
        system:serviceaccount:kube-system:namespace-controller
        system:serviceaccount:kube-system:sealed-secrets-controller
        system:serviceaccount:ldap-sync:ldap-sync
        system:serviceaccount:openshift-apiserver-operator:openshift-apiserver-operator
        system:serviceaccount:openshift-apiserver:openshift-apiserver-sa
        system:serviceaccount:openshift-authentication-operator:authentication-operator
        system:serviceaccount:openshift-authentication:oauth-openshift
        system:serviceaccount:openshift-cloud-credential-operator:cloud-credential-operator
        system:serviceaccount:openshift-cluster-storage-operator:cluster-storage-operator
        system:serviceaccount:openshift-cluster-storage-operator:csi-snapshot-controller-operator
        system:serviceaccount:openshift-cluster-version:default
        system:serviceaccount:openshift-config-operator:openshift-config-operator
        system:serviceaccount:openshift-controller-manager-operator:openshift-controller-manager-operator
        system:serviceaccount:openshift-etcd-operator:etcd-operator
        system:serviceaccount:openshift-etcd:installer-sa
        system:serviceaccount:openshift-image-registry:cluster-image-registry-operator
        system:serviceaccount:openshift-infra:service-serving-cert-controller
        system:serviceaccount:openshift-infra:serviceaccount-pull-secrets-controller
        system:serviceaccount:openshift-infra:template-instance-controller
        system:serviceaccount:openshift-infra:template-instance-finalizer-controller
        system:serviceaccount:openshift-infra:template-service-broker
        system:serviceaccount:openshift-ingress-operator:ingress-operator
        system:serviceaccount:openshift-kube-apiserver-operator:kube-apiserver-operator
        system:serviceaccount:openshift-kube-apiserver:installer-sa
        system:serviceaccount:openshift-kube-apiserver:localhost-recovery-client
        system:serviceaccount:openshift-kube-controller-manager-operator:kube-controller-manager-operator
        system:serviceaccount:openshift-kube-controller-manager:installer-sa
        system:serviceaccount:openshift-kube-controller-manager:localhost-recovery-client
        system:serviceaccount:openshift-kube-scheduler-operator:openshift-kube-scheduler-operator
        system:serviceaccount:openshift-kube-scheduler:installer-sa
        system:serviceaccount:openshift-kube-scheduler:localhost-recovery-client
        system:serviceaccount:openshift-kube-storage-version-migrator-operator:kube-storage-version-migrator-operator
        system:serviceaccount:openshift-kube-storage-version-migrator:kube-storage-version-migrator-sa
        system:serviceaccount:openshift-machine-api:cluster-baremetal-operator
        system:serviceaccount:openshift-machine-config-operator:default
        system:serviceaccount:openshift-machine-config-operator:machine-config-controller
        system:serviceaccount:openshift-monitoring:cluster-monitoring-operator
        system:serviceaccount:openshift-monitoring:prometheus-operator
        system:serviceaccount:openshift-network-operator:default
        system:serviceaccount:openshift-oauth-apiserver:oauth-apiserver-sa
        system:serviceaccount:openshift-operator-lifecycle-manager:olm-operator-serviceaccount
        system:serviceaccount:openshift-operators:pgo
        system:serviceaccount:openshift-service-ca-operator:service-ca-operator
        system:serviceaccount:openshift-user-workload-monitoring:prometheus-operator
        system:serviceaccount:rook-ceph:rook-ceph-system
        system:serviceaccount:velero:velero-server
Groups: okdprod-cluster-admin
        system:cluster-admins
        system:masters

Error during evaluation, results may not be complete: clusterrole.rbac.authorization.k8s.io "system:openshift:scc:hostmount-anyuid" not found

If I run oc access-matrix r secret -n=istio-system It shows that a lot of other groups can delete the secret

NAME                                            KIND            SA-NAMESPACE                                      CREATE  GET  LIST  WATCH  UPDATE  PATCH  DELETE  DELETECOLLECTION
okdprod-cluster-admin                           Group                                                             ✔       ✔    ✔     ✔      ✔       ✔      ✔       ✔
okdprod-cluster-reader                          Group                                                             ✖       ✔    ✔     ✔      ✖       ✖      ✖       ✖
okdprod-cluster-user                            Group                                                             ✔       ✔    ✔     ✔      ✔       ✔      ✔       ✔
okdprod-self-provisioner                        Group                                                             ✔       ✔    ✔     ✔      ✔       ✔      ✔       ✔

I've also verified that "who-can" is correct. The group "okdprod-self-provisioner" can create a secret, but not delete a secret.
But the access-matrix shows that the group can do everything.