Bug: Permissions for authorization introspection APIs not behaving as expected (SSRR, SSAR)

[Felix-Stakater]

Describe the bug

Creating SelfSubjectAccessReveiws and SelfSubjectRulesReviews fails with unauthorized even if the user should have access according to ClusterRole+ClusterRoleBinding in a workspace.

Steps To Reproduce

1. Create new workspace kubectl create-workspace ssrr-poc
2. Deploy the ClusterRole + ClusterRoleBinding below:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: introspection
rules:
- apiGroups:
  - authorization.k8s.io
  resources:
  - selfsubjectaccessreviews
  - selfsubjectrulesreviews
  verbs:
  - create

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: introspection-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: introspection
subjects:
- kind: User
  name: oidc:example@example.com
- kind: Group
  name: system:authenticated

---

SelfSubjectAccessReviews:

run kubectl auth can-i create selfsubjectaccessreviews --as=oidc:example@example.com --as-group=system:authenticated

---

SelfSubjectRulesReviews:

kubectl create --as=oidc:example@example.com -oyaml --validate=false  -f - <<EOF 
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectRulesReview
spec:
  namespace: default
EOF

Expected Behaviour

SelfSubjectAccessReviews:

Expected: Valid response with result.
Observed: Fails with HTTP status 403

---

SelfSubjectRulesReviews:

Expected: Valid response with result
Observed: Error from server (Forbidden): error when creating "STDIN": selfsubjectrulesreviews.authorization.k8s.io is forbidden: User "oidc:example@example.com" cannot create resource "selfsubjectrulesreviews" in API group "authorization.k8s.io" at the cluster scope: access denied

Additional Context

Creating a ClusterRoleBinding to cluster-admin expectedly allows the user to perform both actions.

[mjudeikis]

Thanks, before this being worked, this needs verifying if this is expected behaviour or an issue

[Felix-Stakater]

Ok, thanks for responding. I'm not sure I follow how this could be expected behavior though, as both resources are listed as built in in the documentation. Is it a matter of how to configure the RBAC or are you saying it may be expected that the users are not able to fetch their permissions for the respective workspace?