set `karmada.io/managed` label to all credentials resources

[a7i]

What type of PR is this?

/kind feature

What this PR does / why we need it: Follow-up to https://github.com/karmada-io/karmada/pull/3262

Adds the well-known "karmada.io/managed" label to resources created by karmada controllers

We need a way to bypass creation of some ClusterRole/Rolebindings by our OPA Gatekeeper and we don't have a consistent label to select on. When we join a cluster via push command, it creates ClusterRole/ClusterRoleBinding that are too open (* and *) which is by default blocked by our opa-gatekeeper policies. This allows us to bypass it by the karmada managed label.

Which issue(s) this PR fixes: Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

`karmadactl`: Add the reserved label `karmada.io/managed` to resources created by the `join` command.

[codecov-commenter]

:warning: Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 70.73171% with 12 lines in your changes missing coverage. Please review.

Project coverage is 28.27%. Comparing base (a2e7828) to head (284dd27).

Files	Patch %	Lines
pkg/karmadactl/register/register.go	0.00%	12 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4620      +/-   ##
==========================================
+ Coverage   28.26%   28.27%   +0.01%     
==========================================
  Files         632      632              
  Lines       43589    43612      +23     
==========================================
+ Hits        12319    12332      +13     
- Misses      30372    30382      +10     
  Partials      898      898              

Flag	Coverage Δ
unittests	28.27% <70.73%> (+0.01%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[karmada-bot]

@chaunceyjiang: GitHub didn't allow me to request PR reviews from the following users: a7i.

Note that only karmada-io members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/cc @a7i

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.

[karmada-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: grosser To complete the pull request process, please assign chaunceyjiang after the PR has been reviewed. You can assign the PR to them by writing /assign @chaunceyjiang in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• pkg/controllers/OWNERS
• pkg/karmadactl/OWNERS
• pkg/util/OWNERS

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

[XiShanYongYe-Chang]

Hi @chaunceyjiang, can you help take a review again?

[chaunceyjiang]

/cc @XiShanYongYe-Chang PTAL.

[XiShanYongYe-Chang]

Kindly ping @a7i

[a7i]

Hi @XiShanYongYe-Chang I commented here on the rationale / use-case

[grosser]

@XiShanYongYe-Chang and @whitewindmills would love to get this moving again ... we need a label on these resources, it does not really matter which afaik ManagedByKarmadaLabelValue would make sense, but if we can unblock with a new "ManagedByKarmadaControllerLabel" then that's also fine, just need a clear decision

[a7i]

happy to adjust the PR based on feedback from karmada team.

• do you suggest adding a new label? if so, what should key/value be?

[XiShanYongYe-Chang]

We need to express two semantics, one to indicate that resources in the member clusters are managed by the Karmada system, and the other to indicate that resources on the Karmada control plane are managed by the Karmada system. I propose to distinguish between these two cases, so I came up with two ways:

1. Use two labels to represent this, for example: karmada.io/system: true and karmada.io/managed: true
2. Use different label values to distinguish it, for example: karmada.io/manager: member-cluster and karmada.io/manager: control-plane

Ask more ideas and suggestions from @chaunceyjiang @RainbowMango @whitewindmills @zhzhuang-zju

[whitewindmills]

solution 1 looks good to me.

[RainbowMango]

I'll revisit this tomorrow and get back to you then.

In addition, if we have another choice for OPA to bypass?

What I'm thinking is if we want a label we should make sure every resource that was created during the joining process should have it, not just those credentials resources.

[RainbowMango]

1 Use two labels to represent this, for example: karmada.io/system: true and karmada.io/managed: true 2 Use different label values to distinguish it, for example: karmada.io/manager: member-cluster and karmada.io/manager: control-plane

I vote for option 1, too.

Please @a7i update this PR if you also agree with it.

[XiShanYongYe-Chang]

Kindly ping @a7i

I will also update the labels on the Endpointslice collected on the control plane in sync.

[karmada-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: grosser, RainbowMango

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:

• ~~pkg/karmadactl/OWNERS~~ [RainbowMango]
• ~~pkg/util/OWNERS~~ [RainbowMango]

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

[a7i]

@XiShanYongYe-Chang no rush, but should be ready for your review

[XiShanYongYe-Chang]

OK, thanks~ /retest

[zhzhuang-zju]

/retest

[XiShanYongYe-Chang]

Thanks~ /lgtm

[zhzhuang-zju]

/lgtm and failed e2e cases also rerun successfully~ cc @whitewindmills I observed that you added the /hold label earlier, please take a look at it again for any other comments? Note that once hold is canceled, pr will get merged since there is approve label

[RainbowMango]

/hold cancel