GCP auth plugin is deprecated

[adleong]

trafficstars

What problem are you trying to solve?

The GCP auth plugin that we use in the CLI when connecting to GKE clusters is deprecated. When running a Linkerd command against a GKE cluster, the following warning is printed:

bin/linkerd version
W0819 13:48:08.874900   14571 gcp.go:120] WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.25+; use gcloud instead.
To learn more, consult https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke

How should the problem be solved?

Determine what the replacement for the gcp auth plugin is and use that instead.

Any alternatives you've considered?

N/A

How would users interact with this feature?

No response

Would you like to work on this feature?

No response

[Freyert]

I went through this myself this week, but didn't know what or why.

KEP-541: External credential providers went GA in 1.22 (https://github.com/kubernetes/kubernetes/pull/102181 https://github.com/kubernetes/kubernetes/pull/102890). KEP-541 moves several credential providers out of tree (out of the k8s code base) and to a standardized credential plugin format.

Doing a quick search of the repository I see there's a pkg/k8s/testdata/config.test that includes legacy auth providers:

- name: cluster4
  user:
    auth-provider:
      config:
        access-token: 4cc3sspassatempoq
        cmd-args: config config-helper --format=json
        cmd-path: /Users/bobojones/bin/google-cloud-sdk/bin/gcloud
        expiry: 2017-11-22 22:13:05
        expiry-key: '{.credential.token_expiry}'
        token-key: '{.credential.access_token}'
      name: gcp

The new format would be:

- name: cluster4
   user:
     exec:
        apiVersion: "client.authentication.k8s.io/v1"
        command: "gke-gcloud-auth-plugin"
        provideClusterInfo: true
        interactiveMode: Never

---

Some issues then:

1. Do you need/want to keep supporting the old version as well?
2. Your test tooling will need to upgrade to the new version.

In the end, I would think it might be best to drop provider specific credential plugin testing like this. Kubernetes is moving it out of tree so they don't have to maintain Cloud Provider specific auth and instead rely on the cloud providers themselves to ensure their credential plugins work.

What do you think? Hope this saves some time.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.