🐛 Fix adoption KubeadmControlPlane owned secrets

[killianmuldoon]

Signed-off-by: killianmuldoon kmuldoon@vmware.com

Ensure that KubeadmControlPlane attempts to adopt secrets under its ownerReference on every reconcile. Part of this change ensures that KubeadmConfigController never creates secrets as long as a ControlPlaneReference is set in the Cluster.Spec.

Part of #6979 , #7575

[sbueringer]

/cherry-pick release-1.2

[k8s-infra-cherrypick-robot]

@sbueringer: once the present PR merges, I will cherry-pick it on top of release-1.2 in a new PR and assign it to you.

In response to this:

/cherry-pick release-1.2

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.

[sbueringer]

/cherry-pick release-1.3

[k8s-infra-cherrypick-robot]

@sbueringer: once the present PR merges, I will cherry-pick it on top of release-1.3 in a new PR and assign it to you.

In response to this:

/cherry-pick release-1.3

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.

[killianmuldoon]

/test pull-cluster-api-e2e-full-main

[killianmuldoon]

/test pull-cluster-api-e2e-full-main

[killianmuldoon]

A couple of questions on this one to close out:

1. How should we deal with user supplied certs? Currently the implementation of this PR is to add a controller ownerReference only if the cert is controlled by a KubeadmConfig. In all other cases it will only add a non-controller ownerReference. Note: the only real impact of a controller owner reference is that it's exclusive.
2. What should be done with user-supplied kubeconfigs? This PR takes ownership of the kubeconfig following the naming scheme every time. A user-supplied kube-config would always be adopted in a cluster running KCP.

[sbueringer]

Currently the implementation of this PR is to add a controller ownerReference only if the cert is controlled by a KubeadmConfig

As far as I can tell ensureCertificatesOwnerRef in the KCP controller always adds KCP as owner, not sure what I'm missing that it's only doing that when the cert is controlled by KubeadmConfig.

To be honest, not sure what we want to do here. When they are generated by us it definitely makes sense to have a controller ownerRef. If some other controller is generating them we shouldn't set a controller ownerRef (should we even set an ownerRef at all / do we own a customer generated secret / do we want to delete it on KCP deletion?). I wonder how we can distinguish the cases though. After ownerRefs are reset we can't do it by ownerRef.
Maybe we can decide it based on secret type?

	// ClusterSecretType defines the type of secret created by core components.
	ClusterSecretType corev1.SecretType = "cluster.x-k8s.io/secret" //nolint:gosec

We set it when generating the certs, it's not part of the doc (https://cluster-api.sigs.k8s.io/tasks/certs/using-custom-certificates.html) and the godoc comment explicitly states "secret created by core components".

As far as I can tell "user-supplied" kubeconfig is not a supported scenario and it also doesn't make a lot of sense. We documented how to provide "custom certificates" (https://cluster-api.sigs.k8s.io/tasks/certs/using-custom-certificates.html) but there is no mention of how to use a custom kubeconfig.

[sbueringer]

/retest

[fabriziopandini]

change lgtm to me pending last round of nits + the question about code coverage.
WRT to code coverage, it will be enough for me to have a unit test around adoptKubeconfigSecret (assuming this will be faster than testing all the use cases in TestReconcileKubeconfigSecretDoesNotAdoptsUserSecrets, but I'll defer this to you)

[sbueringer]

Changes so far lgtm from my side.

Feel free to merge independent of another review from my side.

[sbueringer]

Thank you!

/lgtm

/assign @fabriziopandini

[killianmuldoon]

Last change added comments and one more case to the kubeadmconfig secret tests.

[sbueringer]

Looks good as well

/lgtm

[fabriziopandini]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fabriziopandini

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:

• OWNERS [fabriziopandini]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-infra-cherrypick-robot]

@sbueringer: #7592 failed to apply on top of branch "release-1.2":

Applying: Fix KubeadmControlPlane secrets should always be adopted
Using index info to reconstruct a base tree...
M	api/v1beta1/common_types.go
M	bootstrap/kubeadm/internal/controllers/kubeadmconfig_controller.go
M	controlplane/kubeadm/internal/controllers/controller.go
M	controlplane/kubeadm/internal/controllers/controller_test.go
M	controlplane/kubeadm/internal/controllers/helpers.go
M	controlplane/kubeadm/internal/controllers/helpers_test.go
Falling back to patching base and 3-way merge...
Auto-merging controlplane/kubeadm/internal/controllers/helpers_test.go
CONFLICT (content): Merge conflict in controlplane/kubeadm/internal/controllers/helpers_test.go
Auto-merging controlplane/kubeadm/internal/controllers/helpers.go
CONFLICT (content): Merge conflict in controlplane/kubeadm/internal/controllers/helpers.go
Auto-merging controlplane/kubeadm/internal/controllers/controller_test.go
CONFLICT (content): Merge conflict in controlplane/kubeadm/internal/controllers/controller_test.go
Auto-merging controlplane/kubeadm/internal/controllers/controller.go
Auto-merging bootstrap/kubeadm/internal/controllers/kubeadmconfig_controller.go
Auto-merging api/v1beta1/common_types.go
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Fix KubeadmControlPlane secrets should always be adopted
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to this:

/cherry-pick release-1.2

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.

[k8s-infra-cherrypick-robot]

@sbueringer: new pull request created: #7659

In response to this:

/cherry-pick release-1.3

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.