Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃尡 Replicating SyncTarget-related rbac and logicalclusters objects #2933

Conversation

davidfestal
Copy link
Member

@davidfestal davidfestal commented Mar 29, 2023

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

@davidfestal davidfestal requested a review from sttts March 29, 2023 16:09
@openshift-ci openshift-ci bot requested review from csams and jmprusi March 29, 2023 16:09
@openshift-ci openshift-ci bot added the kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API label Mar 29, 2023
@davidfestal davidfestal force-pushed the replicate-synctarget-related-rbac branch 2 times, most recently from a80fec5 to 1e6ee77 Compare March 29, 2023 18:43
@davidfestal
Copy link
Member Author

/test e2e-sharded

@davidfestal davidfestal force-pushed the replicate-synctarget-related-rbac branch from 1e6ee77 to cf8a625 Compare March 30, 2023 10:51
@davidfestal davidfestal force-pushed the replicate-synctarget-related-rbac branch 2 times, most recently from 49b5281 to bcc511f Compare March 30, 2023 12:55
@davidfestal davidfestal force-pushed the replicate-synctarget-related-rbac branch from bcc511f to ae8c468 Compare March 30, 2023 15:04
@davidfestal davidfestal removed the kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API label Mar 30, 2023
@davidfestal
Copy link
Member Author

Just remove the api-changed label since the changes initially done to the API have been removed, since they were finally unnecessary.

@davidfestal
Copy link
Member Author

/test e2e-shared

Copy link
Contributor

@p0lyn0mial p0lyn0mial left a 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!

test/e2e/reconciler/cache/replication_test.go Outdated Show resolved Hide resolved
test/e2e/reconciler/cache/replication_test.go Outdated Show resolved Hide resolved
@@ -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.
Copy link
Contributor

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

ExtraConfig: apiextensionsapiserver.ExtraConfig{

Copy link
Contributor

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 {
Copy link
Member

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.

Copy link
Member Author

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)

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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>
@davidfestal davidfestal force-pushed the replicate-synctarget-related-rbac branch from ae8c468 to 63e6eb5 Compare April 3, 2023 16:34
@davidfestal davidfestal changed the title 馃尡 Replicating SyncTarget-related rbac objects 馃尡 Replicating SyncTarget-related rbac and logicalclusters objects Apr 3, 2023
@davidfestal
Copy link
Member Author

/test e2e-shared

1 similar comment
@davidfestal
Copy link
Member Author

/test e2e-shared

}
resources := sets.NewString(rule.Resources...)
verbs := sets.NewString(rule.Verbs...)
if (resources.Has("synctargets") || resources.Has("*")) && (verbs.Has("sync") || verbs.Has("*")) {
Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Contributor

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("*") {
Copy link
Contributor

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?

Copy link
Member Author

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

@p0lyn0mial
Copy link
Contributor

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Apr 4, 2023
@davidfestal
Copy link
Member Author

/approve

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Apr 4, 2023

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 4, 2023
@openshift-merge-robot openshift-merge-robot merged commit e65e243 into kcp-dev:main Apr 4, 2023
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants