Change:
use cases require a server side component with support for the [webhook token authenticator](#webhook-token-authentication) to interpret the credential format produced by the client plugin. <ins> {{< note >}} Earlier versions of `kubectl` included built-in support for authenticating to AKS and GKE, but this is no longer present. {{< /note >}} </ins> ### Example use case In a hypothetical use case, an organization would run an external service that exchanges LDAP credentials

Discussion:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be (As I understand it), Kubernetes ~v1.25~ v1.26 ships an updated . The updated won't include built-in plugins for authenticating to AKS or GKE. This is likely to surprise folks. Update 3 pages: to signpost users to the right internal ~and external~ docs. We can remove this signposting once Kubernetes v1.27 (sic) is the oldest supported version of Kubernetes (consider adding an HTML comment with that detail). Optionally, also update to mention that earlier versions of included built-in support for authenticating to AKS and GKE, but this is no longer present. Why is this needed Readers may follow the “install kubectl” docs and get a tool that's missing functionality they thought was built in. Comments /sig cli /language en
/triage accepted /priority important-soon
For each of the three pages, add the following under the Verify kubectl configuration heading, at the end of the section:
/help-wanted
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /label help-wanted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository.

</details
/assign
Kubernetes 1.25.0 did not remove Google and Azure auth plugins due to a regression issue, see The revert is in PR
This change is likely to arrive in v1.26, so we should get it staffed.
would you be willing to change the minor version in ?
-- as author/reviewer of the , can you please review the doc change suggested by in
A few suggestions: I probably would not put "panic" in the heading title Can we link to as well I'm on the fence about whether we need the cloud-specific links in this doc... if you try to use them in a kubectl version that has removed them, you already get a message output at time of use with the appropriate link/reference. If we do keep those links, I would say something like "These providers have released kubectl plugins to provide the cloud-specific authentication." instead of "fix the authentication"
I personally do not think the kube authn docs should contain cloud-specific links. It is on the cloud providers to migrate their users anyway, and the cloud CLI tools are fully capable of hiding the bulk of this migration by performing runtime checks and/or preferring credential plugins over the legacy approach.
I agree about not including cloud-provider-specific links. Integrations with cloud providers are not required for a (vanilla) Kubernetes cluster to function. See for some more context.
We can instead advise readers to search in their cloud provider's documentation for further advice.
Hello , 1.26 Release Docs Lead here. This feature request needs Docs for 1.26 release. Please to open a PR against dev-1.26 branch in the k/website repo. This PR can be just a placeholder at this time, and must be created by November 10. Also, take a look at to familiarize yourself with the docs requirement for the release. Any doubt, reach us! Thank you!
/unassign
This issue is labeled with but has not been updated in over 90 days, and should be re-triaged. Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release.

You can: Confirm that this issue is still relevant with (org members only) Deprioritize it with or Close this issue with For more details on the triage process, see /remove-triage accepted
//remove-priority important-soon /priority important-longterm /triage accepted
/remove-priority important-soon
could you kindly provide a detailed description of the issue once more? Upon reviewing the above comments, it appears that numerous changes have been implemented.
looks right to me. In terms of the “right internal and internal docs” to link to, you should use your judgement. You could link to or to a task page; you might need to write the task page first. Any more questions? It's clear to me, but I might have missed something.
/assign
Thanks , I am working on this, will create a PR soon ;)