Skip to content

Add PermissionClaims#304

Merged
mjudeikis merged 2 commits into
kbind-dev:mainfrom
mjudeikis:permission.claims.pooling
Oct 7, 2025
Merged

Add PermissionClaims#304
mjudeikis merged 2 commits into
kbind-dev:mainfrom
mjudeikis:permission.claims.pooling

Conversation

@mjudeikis

@mjudeikis mjudeikis commented Sep 11, 2025

Copy link
Copy Markdown
Contributor

Summary

This adds the ability to claim related resources. For now, it's ServiceAccounts, ConfigMaps and Secrets.
Claims are label-based.
The origin of the resources determines the owner.

High-level design:

  1. Permission Claims are specified using GVR type syntax, same as resource Claims.

  2. LabelSelectors are used to scope down the resources. Based on label selectors, informers will be constructed.
    Label selector is immutable and should be the provider lead. This means the provider determines what it is, and the consumer has no say in the matter. In the future, we could allow consumers to say, but we would need to ship admissionWebhook. And I want to avoid this complexity now.

  3. Permission on provider side - Its either * on the namespace level (when isolation is namespaced, or same on cluster level).

This is mainly as verbs dont quite make sense in kube-bind sense. As you always need more than what might imply. In the end, Kube verbs are ineffective because they are based on informers, requiring specific permissions (list, get, watch) to be used. Since the permission model only applies to konnector to provider only, even if the provider states it needs read (list, watch, get), it is not applicable.

I suggest deferring permission to future enhancement if needed, and even then, make them super flat (read, write, all). But for now, let's keep the API super simple.

  1. Ownership is defined by the fact of where the object was created first - consumer/provider. In the future, we can define "take over conditions". For example, when the Provider seeds the configuration, but the consumer takes over. But this is even possible now by just updating the label to swap owners. Label is automatically added by the reconciler if not specified kube-bind.io/owner=provider/consumer

To see this in action, follow https://github.com/kube-bind/kube-bind/blob/main/contrib/kcp/README.md from the PR.

Permission claim example:

apiVersion: kube-bind.io/v1alpha2
kind: APIServiceExportRequest
metadata:
  name: cowboys.wildwest.dev
spec:
  resources:
  - group: wildwest.dev
    resource: cowboys
    versions:
    - v1alpha1
  permissionClaims:
  - apiGroup: ""
    resource: configmaps
    selector:
      labelSelector:
        matchLabels:
          app: wildwest
  - apiGroup: ""
    resource: secrets
    selector:
      namedResource:
      - name: wildwest-secrets
        namespace: bob

What Type of PR Is This?

/kind feature
/kind api-change

Related Issue(s)

Based on #295 and it must merge first
Fixes: #256

Release Notes

Add basic permission claims to API

Summary by CodeRabbit

  • New Features

    • Permission-claims for selective resource syncing (label & named-resource selectors); exposed across exports, requests, bindings, CRDs, and status.
    • Per-export RBAC provisioning, multiple new controllers (claiming/syncing, namespace provisioning), centralized controller lifecycle store, claimable-API resolver, and UI now consumes typed exported schemas.
    • New helper for determining claimed resources and test client helper.
  • Bug Fixes

    • Legacy namespace identity annotations auto-migrated; RBAC rule added for bound-schema status updates.
  • Documentation

    • Updated contrib/kcp guides and examples.
  • Tests

    • Expanded e2e coverage and new unit tests for selectors and namespace handling.
  • Chores

    • CRD schema/version/storage updates; improved E2E parallelism control and tooling exclusions.

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add permissions claims API into APIServiceExport{Request} and APIServiceBinding

4 participants