-
Notifications
You must be signed in to change notification settings - Fork 39.8k
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
[Federation] Use service accounts instead of the user's credentials when accessing joined clusters' API servers. #42042
Conversation
Hi @perotinus. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
@irfanurrehman can you review this? I will also try to do a pass. |
@madhusudancs, yes, certainly! |
Review status: 0 of 6 files reviewed at latest revision, 26 unresolved discussions. federation/cluster/federation-up.sh, line 98 at r1 (raw file):
Any specific reason for this change? federation/pkg/federation-controller/util/cluster_util.go, line 69 at r1 (raw file):
you can as well pass the secret to this function, which u already have here. federation/pkg/federation-controller/util/cluster_util.go, line 72 at r1 (raw file):
you return nil, nil in case SecretRef.Name == nil from GetSecret() , which unnecessarily traces the rest of the code.
You can as well format an error in return from GetSecret() or handle the scenario here itself, with this check not needed inside GetSecret() federation/pkg/federation-controller/util/cluster_util.go, line 78 at r1 (raw file):
Assigning to clusterConfig without verifying error, clusterConfig could be null? federation/pkg/federation-controller/util/cluster_util.go, line 97 at r1 (raw file):
U can as well pass the secret object here, rather then the cluster object, because u already have it earlier. federation/pkg/federation-controller/util/cluster_util.go, line 100 at r1 (raw file):
you sort of have already done this check earlier (in BuildClusterConfig at line 65), and then call KubeconfigGetterForCluster(), so probably not needed here again. federation/pkg/federation-controller/util/cluster_util.go, line 109 at r1 (raw file):
s/GetterForSecret/GetSecret federation/pkg/federation-controller/util/cluster_util.go, line 110 at r1 (raw file):
You need not export the function if used only here. federation/pkg/federation-controller/util/cluster_util.go, line 148 at r1 (raw file):
As in the comment on line 97, you probably don't need the nested function. federation/pkg/kubefed/join.go, line 148 at r1 (raw file):
I think this might need implementation now, rather then a TODO, otherwise registering older version clusters would fail, which works now and we do not want to break that. federation/pkg/kubefed/join.go, line 150 at r1 (raw file):
The info message ideally should be complete because we create somethings in target cluster and somethings in base cluster.
|
e9ab646
to
855ee31
Compare
Thanks for the review! I have a few questions, so I've left a few Given the code freeze coming up, I'm not sure how much of the TODO work I'll be able to get done and tested. I think supporting old clusters is probably pretty important, so I'm going to start on that now. Review status: 0 of 5 files reviewed at latest revision, 26 unresolved discussions. federation/pkg/federation-controller/util/cluster_util.go, line 69 at r1 (raw file): Previously, irfanurrehman wrote…
Done, as per your comment below about removing GetterForCluster(). This is definitely cleaner. Thanks! federation/pkg/federation-controller/util/cluster_util.go, line 72 at r1 (raw file): Previously, irfanurrehman wrote…
I've reworked this, so this shouldn't be a problem anymore. Thanks! federation/pkg/federation-controller/util/cluster_util.go, line 78 at r1 (raw file): Previously, irfanurrehman wrote…
Yes, that's my bad. I went through and added error handling but missed this one. federation/pkg/federation-controller/util/cluster_util.go, line 97 at r1 (raw file): Previously, irfanurrehman wrote…
Done. federation/pkg/federation-controller/util/cluster_util.go, line 100 at r1 (raw file): Previously, irfanurrehman wrote…
Thanks! This code is gone now, so this is fixed. federation/pkg/federation-controller/util/cluster_util.go, line 109 at r1 (raw file): Previously, irfanurrehman wrote…
Yep. This was a copy-paste mistake. All fixed. federation/pkg/federation-controller/util/cluster_util.go, line 110 at r1 (raw file): Previously, irfanurrehman wrote…
Done. federation/pkg/federation-controller/util/cluster_util.go, line 148 at r1 (raw file): Previously, irfanurrehman wrote…
Done. federation/pkg/kubefed/join.go, line 150 at r1 (raw file): Previously, irfanurrehman wrote…
Done. federation/pkg/kubefed/join.go, line 151 at r1 (raw file): Previously, irfanurrehman wrote…
Done. federation/pkg/kubefed/join.go, line 153 at r1 (raw file): Previously, irfanurrehman wrote…
Done. federation/pkg/kubefed/join.go, line 158 at r1 (raw file): Previously, irfanurrehman wrote…
Done. federation/pkg/kubefed/join.go, line 249 at r1 (raw file): Previously, irfanurrehman wrote…
Done. federation/pkg/kubefed/join.go, line 259 at r1 (raw file): Previously, irfanurrehman wrote…
Hmm. I think I'd prefer to keep this the way it is; this function has no way of knowing that the passed-in client set is for a joining cluster, and I'd rather not make assumptions about the arguments in the logs. WDYT? federation/pkg/kubefed/join.go, line 265 at r1 (raw file): Previously, irfanurrehman wrote…
Done. federation/pkg/kubefed/join.go, line 268 at r1 (raw file): Previously, irfanurrehman wrote…
Hmm. That's a good point; I didn't know that clusters could join multiple federations. What would be unique to those two federation clusters? My concern is that unjoin (when implemented) will need to be able to delete these deterministically, and with a random identifier, that will be not as easy. I see your comment below. I've added a TODO about this. federation/pkg/kubefed/join.go, line 277 at r1 (raw file): Previously, irfanurrehman wrote…
Done. #2 was easy to implement, and is certainly more unique, so I did it. federation/pkg/kubefed/join.go, line 278 at r1 (raw file): Previously, irfanurrehman wrote…
I suppose we could use the existing service account. I preferred to recreate it anew and not use the existing secret data, but I'm not strongly attached to this idea. Does anyone see an issue with reusing the service account and its credentials for the new cluster? Actually, this might be a hacky workaround to the "cluster in multiple federations" issue: two federations with the same name will have the same service account, and can reuse credentials. This seems not great, but it would work. The secret in the joining cluster would be deleted when the SA is deleted, I believe, though I haven't verified this. federation/pkg/kubefed/join.go, line 292 at r1 (raw file): Previously, irfanurrehman wrote…
Agreed. Leaving this for now, until we decide about using the existing service account. federation/pkg/kubefed/join.go, line 325 at r1 (raw file): Previously, irfanurrehman wrote…
Not exactly. This is a ClusterRoleBinding, which lives outside of namespaces and allows access to all resources. I originally tried using regular RoleBindings, but even with all roles allowed they didn't have access to resources in other namespaces. Here, I believe that the namespace argument says "bind the SA named saName in namespace", rather than affecting the ClusterBinding's namepsace. federation/pkg/kubefed/join.go, line 357 at r1 (raw file): Previously, irfanurrehman wrote…
You are correct. Thanks! federation/pkg/kubefed/join.go, line 380 at r1 (raw file): Previously, irfanurrehman wrote…
That's a good point. THanks! federation/pkg/kubefed/unjoin.go, line 77 at r1 (raw file): Previously, irfanurrehman wrote…
Absolutely! I had deferred this until a pass on the rest of the code. I might do it in a follow-up PR, since there is a manual workaround ATM (ie, lots of kubectl deletes) federation/pkg/kubefed/util/util.go, line 50 at r1 (raw file): Previously, irfanurrehman wrote…
I've removed this, in favor of a bit more uniqueness. federation/cluster/federation-up.sh, line 98 at r1 (raw file): Previously, irfanurrehman wrote…
Well, there was: I forgot to push my latest changes after I removed the debugging code. :) Sorry about that! Comments from Reviewable |
@perotinus, please update me once you want me to have a look again! |
@irfanurrehman I think you can take a look now; I've replied to all of your previous comments, and I think that @madhusudancs (I believe; correct me if I've remembered wrong, Madhu) suggested that I do the rest of the TODO work in follow-up PRs. Madhu also suggested that I rebase this PR off of your PR that checks for the RBAC version on the API server. I took a look and I'm not sure it'll fully solve my problem here: it looks like you assume that the API server will support some version of RBAC, where I need to check whether the server supports RBAC at all and use the old behavior if it does not. I can use your code when I make the RBAC calls, but will need a parallel check for the existence of the RBAC group at all. Thanks! |
@perotinus, I think the reason @madhusudancs suggested you to rebase on top of mine is because, u would need to solve the conflicts anyways (there are changes in common part of the code), when it comes to merging.. :-). |
Review status: 0 of 5 files reviewed at latest revision, 26 unresolved discussions. federation/pkg/federation-controller/util/cluster_util.go, line 72 at r1 (raw file): Previously, perotinus (Jonathan MacMillan) wrote…
@perotinus, have you pushed ur changes. federation/pkg/federation-controller/util/cluster_util.go, line 78 at r1 (raw file): Previously, perotinus (Jonathan MacMillan) wrote…
same here, Comments from Reviewable |
855ee31
to
95c9878
Compare
403f745
to
68f560b
Compare
@irfanurrehman OK, this should be updated now. I've rebased as well. PTAL when you get a chance. Not sure what happened this weekend. Sorry about that! |
@perotinus, please go ahead and implement the unit test also for this. |
3783b25
to
98f119b
Compare
b79484b
to
d02e056
Compare
@k8s-bot test this |
Awesome! Thanks for digging through these issues and fixing them. Requires a rebase and I have a few minor comments. Mostly nits. Let me know once you address them. I will apply the labels. Reviewed 4 of 7 files at r6, 4 of 7 files at r7. federation/pkg/federation-controller/util/cluster_util.go, line 81 at r4 (raw file): Previously, perotinus (Jonathan MacMillan) wrote…
Yeah! Although it's verbose, it is very clear that if you have one or the other then execute the if block. federation/pkg/kubefed/join.go, line 160 at r4 (raw file):
Why remove this? federation/pkg/kubefed/join.go, line 568 at r4 (raw file):
Not necessary anymore? federation/pkg/kubefed/join.go, line 502 at r7 (raw file):
I am somewhat confused about this. May be rebase? federation/pkg/kubefed/join_test.go, line 445 at r7 (raw file):
Can we call this variable something else? It doesn't matter that much, this is a test code and it is only used here, but it is worth differentiating the function name and the variable name. But I don't feel too strongly about it. So feel free to ignore as well. federation/pkg/kubefed/join_test.go, line 597 at r7 (raw file):
Just directly call the function here instead of trying to rename the variable here. I think that's Ok because it's test code. federation/pkg/kubefed/unjoin.go, line 322 at r7 (raw file):
I really dislike the err := unjoiningClusterClientset.Rbac().ClusterRoleBindings().Delete(clusterRoleName, &metav1.DeleteOptions{})
if err != nil && !errors.IsMethodNotSupported(err) && !errors.IsNotFound(err) {
...
} ? federation/pkg/kubefed/unjoin.go, line 325 at r7 (raw file):
Same here. Comments from Reviewable |
Review status: 6 of 11 files reviewed at latest revision, 14 unresolved discussions. federation/pkg/kubefed/join.go, line 160 at r4 (raw file): Previously, madhusudancs (Madhusudan.C.S) wrote…
Oh, I remember now: sa was always non-nil, it was just empty if there was no service account in the cluster, so this check wasn't doing anything. I assumed this was due to a change elsewhere in Kubernetes. I suppose I could re-add this with a more complicated check that the SA is non-empty. federation/pkg/kubefed/join.go, line 568 at r4 (raw file): Previously, madhusudancs (Madhusudan.C.S) wrote…
I think I removed this because the caller was also logging. federation/pkg/kubefed/join.go, line 502 at r7 (raw file): Previously, madhusudancs (Madhusudan.C.S) wrote…
Done. federation/pkg/kubefed/join_test.go, line 445 at r7 (raw file): Previously, madhusudancs (Madhusudan.C.S) wrote…
Done. federation/pkg/kubefed/join_test.go, line 597 at r7 (raw file): Previously, madhusudancs (Madhusudan.C.S) wrote…
Hmm. I use saName just below as well, so I think I have to create the local variable. federation/pkg/kubefed/unjoin.go, line 322 at r7 (raw file): Previously, madhusudancs (Madhusudan.C.S) wrote…
Done. federation/pkg/kubefed/unjoin.go, line 325 at r7 (raw file): Previously, madhusudancs (Madhusudan.C.S) wrote…
Done. Comments from Reviewable |
@madhusudancs OK, this should be ready for re-review now. |
Reviewed 3 of 7 files at r7, 2 of 2 files at r8. federation/pkg/kubefed/join.go, line 160 at r4 (raw file): Previously, perotinus (Jonathan MacMillan) wrote…
The problem is, this code is now not achieving what we want, i.e. making sure the object doesn't exist. I would suggest restructuring this as: // Make sure there is no existing service account in the joining cluster.
saName := util.ClusterServiceAccountName(j.commonOptions.Name, j.commonOptions.Host)
sa, err = rbacVersionedClientset.Core().ServiceAccounts(j.commonOptions.FederationSystemNamespace).Get(saName, metav1.GetOptions{})
if errors.IsNotFound(err) {
return nil
} else if err != nil {
return err
} else if sa != nil {
return fmt.Errorf("service account already exists in joining cluster")
} My suspicion is somewhere in the if err != nil {
return &v1.ServiceAccount{}, err
} whereas the convention is to if err != nil {
return nil, err
} This explains why you are getting an empty object. So checking for the errors first and then the service account object helps here. Makes sense? federation/pkg/kubefed/join.go, line 568 at r4 (raw file): Previously, perotinus (Jonathan MacMillan) wrote…
Ok. Comments from Reviewable |
Review status: 10 of 11 files reviewed at latest revision, 8 unresolved discussions, some commit checks failed. federation/pkg/kubefed/join.go, line 160 at r4 (raw file): Previously, madhusudancs (Madhusudan.C.S) wrote…
Done. Comments from Reviewable |
…hen accessing joined clusters' API servers.
@perotinus thanks for fighting through this! And finally! Everything LGTM, but let's wait for federation presubmits situation to settle down before adding the labels. Reviewed 1 of 1 files at r9, 1 of 1 files at r10. Comments from Reviewable |
@k8s-bot pull-kubernetes-federation-e2e-gce test this |
/lgtm Finally! |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: janetkuo, madhusudancs, perotinus
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
@perotinus: The following test(s) failed:
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Automatic merge from submit-queue (batch tested with PRs 42042, 46139, 46126, 46258, 46312) |
Fixes #41267.
Release notes: