bug: access denied for permissionClaim on tenancy.kcp.io resources

[ljmsc]

Describe the bug

I have a kcp setup with three workspaces (root, provider and consumer). In the provider workspace I have an APIExport which looks like this:

apiVersion: apis.kcp.io/v1alpha2
kind: APIExport
metadata:
  name: example.com
spec:
  resources:
    - group: example.com
      name: testresources
      schema: provider-v20260217.testresources.example.com
      storage:
        crd: {}
  permissionClaims:
    - group: ""
      resource: events
      verbs: ["list", "watch", "get"]
    - group: tenancy.kcp.io
      resource: workspaces
      identityHash: <identityHash>
      verbs: ["get", "list", "watch"]

For the controller which should access the resulting virtual workspace, I have an service account (also in the provider workspace) and a role + rolebinding to grant permission to the content of the virtual workspace.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sa-role
rules:
  - apiGroups: ["apis.kcp.io"]
    verbs: ["list", "watch", "get"]
    resources:
      - apiexportendpointslices
  - apiGroups: ["apis.kcp.io"]
    verbs: ["*"]
    resources: ["apiexports/content"]
    resourceNames: ["example.com"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: sa-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: sa-role
subjects:
  - kind: ServiceAccount
    name: provider-sa
    namespace: provider-ns

In the consumer workspace I have an APIBinding which looks like this:

apiVersion: apis.kcp.io/v1alpha2
kind: APIBinding
metadata:
  name: example.com
spec:
  reference:
    export:
      name: example.com
      path: "root:provider"
  permissionClaims:
    - group: ""
      resource: events
      verbs: ["list", "watch", "get"]
      selector:
        matchAll: true
      state: Accepted
    - group: tenancy.kcp.io
      resource: workspaces
      identityHash: <identityHash>
      verbs: ["get", "list", "watch"]
      selector:
        matchAll: true
      state: Accepted

When I try to access the virtual workspace with the service account I can access the resources defined in the APIExport but not the ones from the permissionClaim in the group tenancy.kcp.io.

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "workspaces.tenancy.kcp.io is forbidden: User \"system:serviceaccount:provider-ns:provider-sa\" cannot list resource \"workspaces\" in API group \"tenancy.kcp.io\" at the cluster scope: access denied",
  "reason": "Forbidden",
  "details": {
    "group": "tenancy.kcp.io",
    "kind": "workspaces"
  },
  "code": 403
}

If I use the "admin-token", I can access everything just fine. Do I need to extend the role / rolebinding somehow?

Steps To Reproduce

Create a APIExport with an permissionClaim to workspaces.tenancy.kcp.io in an extra workspace.

Expected Behaviour

I can access the resource information from workspaces.tenancy.kcp.io since I granted access to the apiexports/content resource in the provider workspace.

Additional Context

For debugging I use the following command:

$ curl -k -XGET "https://kcp:8443/services/apiexport/<provider workspace cluster id>/example.com/clusters/*/apis/tenancy.kcp.io/v1alpha1/workspaces" \
--header "Authorization: Bearer <sa-token>"

[mjudeikis-bot]

After chatting with @mjudeikis, the suggestion is that apiexports/content access alone may not be sufficient for permissionClaim resources — the SA also needs an explicit RBAC rule for the claimed resource itself.

Worth trying to add to your ClusterRole:

- apiGroups: ["tenancy.kcp.io"]
  resources: ["workspaces"]
  verbs: ["get", "list", "watch"]

See if that clears the 403. For reference, the platform-mesh provider-quickstart explicitly grants rules for each resource the controller needs — that pattern likely applies to permissionClaim resources too.

[mjudeikis]

@ljmsc please ping me on slack nex t tiem and in #kcp-users channel :) sorry I missed it

[mjudeikis-bot]

Also for reference, here are working examples of permissionClaims from platform-mesh-operator:

• APIBinding with accepted permissionClaims: https://github.com/platform-mesh/platform-mesh-operator/blob/main/manifests/kcp/01-platform-mesh-system/apibinding-core-platform-mesh.io.yaml#L7-L12
• APIExport with permissionClaims declared: https://github.com/platform-mesh/platform-mesh-operator/blob/main/manifests/kcp/01-platform-mesh-system/apiexport-core.platform-mesh.io.yaml#L17-L20

Might help to compare what resource groups are claimed there vs tenancy.kcp.io.

[ljmsc]

hey @mjudeikis @mjudeikis-bot , thanks for the reply. Unfortunately the platform-mesh provider-quickstart is not using a permissionClaim. For the actual resource, the access works fine for me. Only the resources from the permissionClaim are affected. the examples from the platform-mesh-operator do not include the actual rolebinding which would be the important path.
I already tried to grant access directly to the workspaces resource but this didn't work either.

[mjudeikis-bot]

Hey @ljmsc, thanks for the clarification — that’s helpful context.

If direct RBAC on workspaces didn’t work and the platform-mesh quickstart isn’t using a permissionClaim, the next thing to check is the permissionClaim acceptance flow end-to-end:

1. Verify the permissionClaim is accepted in the APIBinding — check that your APIBinding has an acceptedPermissionClaims entry that exactly matches the group/resource declared in the APIExport (including the identityHash). A mismatch in identityHash silently blocks the claim.

2. Check the SyncTarget / APIExport virtual workspace SA — the SA that kcp grants permissions to for claimed resources is the one associated with the APIExport’s virtual workspace, not a regular cluster SA. You can find it by inspecting the APIExport status for the virtual workspace URL.

3. Look at kcp controller logs for permission syncer errors — kcp should log if it tried to reconcile permissions for a claimed resource and failed. Something like permissionclaim in the log filter.

4. Double-check the claimed resource spec — in the APIExport, the permissionClaims entry needs the exact group + resource that matches what kcp will look up. For tenancy.kcp.io/workspaces, confirm the identityHash is set (or omitted correctly for built-in types).

The missing rolebinding you mentioned is likely the one kcp creates automatically in the consumer workspace when the permissionClaim is properly accepted — if it’s not appearing, the claim acceptance itself is probably not completing. Running kubectl get apibinding <name> -o yaml and checking .status.conditions should show if there’s a rejection reason.

Happy to dig further if you can share the APIExport + APIBinding YAML (redacted as needed).

[mjudeikis]

@mjudeikis-bot you creating noise now :D stop
@ljmsc I will try to replicate this, give me some time