rakkess
rakkess copied to clipboard
inconsistency between access-matrix and "oc who-can"
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: e52bef14064d68573850f4f64f825b7be4800457 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.