New plugin: gke-exec-credential

[jglick]

https://github.com/jglick/gke-exec-credential/blob/master/README.md#gke-exec-credential and see kubernetes/kubernetes#62185

---

Checklist for plugin developers:

• Read the Plugin Naming Guide (for new plugins)
• Verify the installation from URL or a local archive works (kubectl krew install --manifest=[...] --archive=[...])

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[ahmetb]

Thanks for the PR. I'll currently put this on hold, as we're considering allowing only official vendors to allow submitting plugins with the vendor prefix (in this case gke-) to the centralized plugin index.

We haven't yet come to a decision about the plugin acceptance criteria, but will do soon.

---

Aside from that, I think (since I work on GKE) we should probably distribute a credential retriever binary ourselves as part of gcloud SDK that's automatically installed (just like docker credentials helper for GCR).

[ahmetb]

I've found several other reasons why this might not be suitable for a distribution via krew's centralized index:

• users don't directly call this tool, plugins are mostly intended to be visible to the users and enhance kubectl's behavior.
• I think most users won't be editing their GKE kubeconfigs to reference this tool.

I don't see a clear benefit to this tool than GKE's current model where we create per-context "user" entry (sure, it's wasteful, but that's something GKE command can probably fix).

I'm curious about why you’re developing this plugin and why you think it's beneficial. Feel free to drop me a line at {my-username}@google.com.

[jglick]

we're considering allowing only official vendors to allow submitting plugins with the vendor prefix […] to the centralized plugin index

Ah, something to mention in the naming guide?

(since I work on GKE) we should probably distribute a credential retriever binary ourselves as part of gcloud SDK

Of course I would be happy to close this if that is in the works! Since my script merely massages the JSON output a bit from an existing gcloud subcommand, presumably it would not be much work to do that upstream.

I don't see a clear benefit to this tool than GKE's current model where we create per-context "user" entry

The redundancy (when you have multiple clusters registered) is an annoyance, but independent of this tool since you could of course manually deduplicate.

why you’re developing this plugin and why you think it's beneficial

Perhaps the README was not sufficiently clear. The purpose of this tool is to help migrate towards the newer and more generic authentication method, to reduce the pressure on clients to perfect support for older vendor-specific methods such as gcp. See kubernetes-client/java#290 (comment) for an example.

[ahmetb]

The purpose of this tool is to help migrate towards the newer and more generic authentication method

But when users run gcloud [...] get-credentials again, that benefit will be reverted, as the new context entries won't be using the auth plugin you developed?

Also, right now this plugin is just 1-line, I'm not sure if it's something we should be accepting to the main repo as it is.

gcloud config config-helper --format=json "$@" | jq '{"apiVersion": "client.authentication.k8s.io/v1beta1", "kind": "ExecCredential", "status": {"token": .credential.access_token, "expirationTimestamp": .credential.token_expiry}}'

Ideally this should be distributed as part of gcloud ––if there's a need. Right now our team doesn't see a clear benefit for it. You will still be depending on gcloud to be in $PATH.

P.S. If you would like to authenticate to GKE in headless environments, you can just use the GOOGLE_APPLICATION_CREDENTIALS env variable to supply credentials and delete the part of the users entry that calls out to gcloud, this way, you actually don't need gcloud to be installed.

[jglick]

But when users run gcloud [...] get-credentials again, that benefit will be reverted

That is why when running this command I back up my ~/.kube/config, run it, copy out the server URL & credentials, revert to backup, and then copy in the context entries. Even before switching to this mode I did the same workflow, since get-credentials gratuitously reformats everything and I want this file versioned.

Ideally this should be distributed as part of gcloud

Yes that would be nice.

You will still be depending on gcloud to be in $PATH.

Correct, just using a more general authentication method than gcp.

[ahmetb]

/hold

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[ahmetb]

/remove-lifecycle stale

/cc @corneliusweig
I'm in a dilemma:

I feel like we should only accept plugins that are directly used interactively (e.g. kubectl foo) by the user and we shouldn't be a vessel for adding other sorts of kubernetes binaries to PATH.

But at the same time, credential plugins are recognized by kubectl, and we are a kubectl plugin manager (despite the two things are not the same thing), we can use krew's ability to ship multi-platform binaries to PATH and have other kubectl commands use these sorts of creds plugins independently. This would broaden krew's use cases.

I think we'll need more data/evidence or agreement on whether these should be admitted or not.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closed this PR.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/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/test-infra repository.