-
Notifications
You must be signed in to change notification settings - Fork 386
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🌱 Replicating SyncTarget-related rbac and logicalclusters objects #2933
🌱 Replicating SyncTarget-related rbac and logicalclusters objects #2933
Conversation
pkg/reconciler/workload/replicateclusterrole/replicateclusterrole_controller.go
Outdated
Show resolved
Hide resolved
a80fec5
to
1e6ee77
Compare
/test e2e-sharded |
1e6ee77
to
cf8a625
Compare
49b5281
to
bcc511f
Compare
bcc511f
to
ae8c468
Compare
Just remove the |
/test e2e-shared |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just 2 nits, lgtm other than that, thx!
@@ -678,14 +683,23 @@ func (b *replicateResourceScenario) verifyResourceReplicationHelper(ctx context. | |||
} | |||
unstructured.RemoveNestedField(originalResource.Object, "metadata", "resourceVersion") | |||
unstructured.RemoveNestedField(cachedResource.Object, "metadata", "resourceVersion") | |||
|
|||
// TODO(davidfestal): find out why the generation is not equal, specially for rbacv1. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. I think I found it: kcp-dev/kubernetes#132
Once this PR merges we need to set the field to true
in
kcp/pkg/cache/server/config.go
Line 203 in 0d6a2ae
ExtraConfig: apiextensionsapiserver.ExtraConfig{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could wait until the PR merges and test it in your PR, wdyt?
} | ||
resources := sets.NewString(rule.Resources...) | ||
verbs := sets.NewString(rule.Verbs...) | ||
if resources.Has("synctargets") && verbs.Has("sync") && len(rule.ResourceNames) == 1 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
len(rule.ResourceNames) == 1
is logically wrong. Multiple resource names are possible and a user could use those for custom authorization of a syncer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would > 0
be OK ?
I can also of course completely remove this condition (which was the case initially)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But considering the case when a single service account would grant access to the VWs for all the SyncTargets seems strange to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The RBAC semantics is well defined. If RBAC authorizes syncing, you must replicate the role. Don't let this logic be influenced by how the cli command sets things up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed this, and also now take in account the *
in the rules, as done for the APIExport-related rbac objects.
Signed-off-by: David Festal <dfestal@redhat.com>
Signed-off-by: David Festal <dfestal@redhat.com>
Signed-off-by: David Festal <dfestal@redhat.com>
ae8c468
to
63e6eb5
Compare
/test e2e-shared |
1 similar comment
/test e2e-shared |
} | ||
resources := sets.NewString(rule.Resources...) | ||
verbs := sets.NewString(rule.Verbs...) | ||
if (resources.Has("synctargets") || resources.Has("*")) && (verbs.Has("sync") || verbs.Has("*")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't we match on Verbs: []string{"sync"}, Resources: []string{"synctargets"}
only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, in fact I came back to what @sttts had done for APIExports (quite similar use-case): https://github.com/kcp-dev/kcp/blob/main/pkg/reconciler/apis/replicateclusterrole/replicateclusterrole_controller.go#L58
That mainly covers all the CRs that would allow the sync
verb for synctargets
resources
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, thanks for explaining.
func HasSyncRule(clusterName logicalcluster.Name, cr *rbacv1.ClusterRole) bool { | ||
for _, rule := range cr.Rules { | ||
apiGroups := sets.NewString(rule.APIGroups...) | ||
if !apiGroups.Has(workload.GroupName) && !apiGroups.Has("*") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't we match on APIGroups: []string{"workload.kcp.io"}
only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, in fact I came back to what @sttts had done for APIExports (quite similar use-case): https://github.com/kcp-dev/kcp/blob/main/pkg/reconciler/apis/replicateclusterrole/replicateclusterrole_controller.go#L58
That mainly covers all the CRs that would allow the sync
verb for synctargets
resources
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: davidfestal The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Summary
The SyncTarget-related cluster roles and cluster role bindings, as well as logical clusters, should be replicated in order to have the Syncer virtual workspace work correctly.
Related issue(s)
This is a split of PR #2675