Add PermissionClaims#304
Merged
Merged
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
Permission Claims are specified using
GVRtype syntax, same as resource Claims.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.
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
konnectortoprovideronly, even if the provider states it needsread(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.
kube-bind.io/owner=provider/consumerTo see this in action, follow https://github.com/kube-bind/kube-bind/blob/main/contrib/kcp/README.md from the PR.
Permission claim example:
What Type of PR Is This?
/kind feature
/kind api-change
Related Issue(s)
Based on #295 and it must merge firstFixes: #256
Release Notes
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Tests
Chores