`kubectl karmada join` does not support `--context --as --as-group`

[grosser]

What would you like to be added: support for these 3 flags

Why is this needed: otherwise I need to setup a special context and use-context to be able to use join

[RainbowMango]

For the --context, karmadactl(same as kubectl karmada) provides the two flags to specify the context for both karmada and member cluster:

    --cluster-context='':
	Name of cluster context in kubeconfig. The current context is used by default.
    --karmada-context='':
	The name of the kubeconfig context to use

Given karmadatl join might need two kubeconfigs, just one --context might be misleading as it can't represent which kubeconfig it applies to.

Please let us know if the two flags meet your needs. Maybe I didn't understand your use case yet.

[RainbowMango]

For the --as and --as-group, I guess you mean the two flags in kubectl:

    --as='':
	Username to impersonate for the operation. User could be a regular user or a service account in a namespace.

    --as-group=[]:
	Group to impersonate for the operation, this flag can be repeated to specify multiple groups.

I'd like to hear more details about the use case if you don't mind. We also need to consider which kubeconfig the two flags will be applied.

[grosser]

I'd need to impersonate admin on the host cluster, so --cluster-as

[grosser]

hmmm no the host cluster would be --karmada-as :)

[RainbowMango]

Yes, --karmada-as and --karmada-as-group are sounds good to me. cc @XiShanYongYe-Chang What do you think?

[XiShanYongYe-Chang]

These two flags look good, but I don't understand one thing. Why do you need to use impersonate to join a cluster in Karmada?

[grosser]

I need to be cluster admin to join the cluster, our default context is read-only.

On Mon, Mar 11, 2024, 7:18 PM Chang @.***> wrote:

These two flags look good, but I don't understand one thing. Why do you need to use impersonate to join a cluster in Karmada?

— Reply to this email directly, view it on GitHub https://github.com/karmada-io/karmada/issues/4695#issuecomment-1989831087, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACYZ4LLXPBVSLK725ZHNTYXZQW3AVCNFSM6AAAAABERCJRJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBZHAZTCMBYG4 . You are receiving this because you authored the thread.Message ID: @.***>

[XiShanYongYe-Chang]

I need to be cluster admin to join the cluster, our default context is read-only.

Is this safe? Should the admin user be the one to join the cluster?

[grosser]

It needs to be the admin user since the read-only user can't do it. We do the same ATM by adding a new context first and then use use-context.

On Mon, Mar 11, 2024, 7:26 PM Chang @.***> wrote:

I need to be cluster admin to join the cluster, our default context is read-only.

Is this safe? Should the admin user be the one to join the cluster?

— Reply to this email directly, view it on GitHub https://github.com/karmada-io/karmada/issues/4695#issuecomment-1989852591, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACYZ4L3KNGCCEBPO452OLYXZRWRAVCNFSM6AAAAABERCJRJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBZHA2TENJZGE . You are receiving this because you authored the thread.Message ID: @.***>

[XiShanYongYe-Chang]

It needs to be the admin user since the read-only user can't do it.

So you need to have the read-only user act as the admin user to join the cluster, is that correct?

We do the same ATM by adding a new context first and then use use-context.

Sorry, I didn't quite understand that sentence. Can you explain it a little more?

[grosser]

A: yes B: atm we make define a foo-admin context that connects to the same user that we otherwise want to assume, so I think with --as support things should just work

[XiShanYongYe-Chang]

Thanks~ Would you like to contribute?

[grosser]

I can give it a try

[RainbowMango]

kindly ping @grosser are you still working on this? Do you need any help?

[grosser]

ah sry never got around to it 😞 best don't add a milestone, I'll give it another try when I find some time

[RainbowMango]

no rush, take your time :)

[grosser]

https://github.com/karmada-io/karmada/pull/5016 for the --karmada-as-* flags ... getting the context set was more complicated so leaving that for another PR

[XiShanYongYe-Chang]

getting the context set was more complicated so leaving that for another PR

Is it possible to submit them in one PR? Currently, only the flag is submitted, and there is no corresponding processing logic. I'm afraid that they are not in the same version, which may cause misunderstanding to the user.

[grosser]

the PR adds the --as-* and sets them on the client, I though that would do the trick ? (context flag + setting it on the client can be a standalone PR)

[XiShanYongYe-Chang]

In favor of #5016 /assign @grosser

the PR adds the --as-* and sets them on the client, I though that would do the trick ?

Hi @grosser, I think it will be ok, have you tested with the PR?

[XiShanYongYe-Chang]

Thanks @grosser ~ You have completed the tasks in this issue. Let me close this issue. Feel free to re-open this issue if you need any help. /close

[karmada-bot]

@XiShanYongYe-Chang: Closing this issue.

In response to this:

Thanks @grosser ~ You have completed the tasks in this issue. Let me close this issue. Feel free to re-open this issue if you need any help. /close

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-sigs/prow repository.