Yes. Kubernetes supports client-go credential plugins, stable since v1.22, where kubectl runs an external command that returns credentials for your identity system. Your kubeconfig then names a command instead of storing a permanent token, which shrinks what a stolen kubeconfig is worth.
What the feature is
The Kubernetes authentication documentation says k8s.io/client-go, and tools that use it such as kubectl and kubelet, can execute an external command to receive user credentials. The feature is intended for client side integrations with authentication protocols not natively supported by client-go, such as LDAP, Kerberos, OAuth2 or SAML. The plugin handles the protocol, then returns opaque credentials to use.
The docs call it stable since Kubernetes v1.22.
How a kubeconfig references a plugin
In the users section of kubeconfig, an exec block names the command to run, the API version used to decode the ExecCredential resource, optional arguments and optional environment variables to set while running it. The plugin can return a token, or a PEM encoded client certificate and key for TLS client authentication.
A sketch of the shape, with placeholder names:
users:
- name: dev-user
user:
exec:
apiVersion: client.authentication.k8s.io/v1
command: example-login-plugin
args:
- get-credentials
The plugin in the docs' example prompts for a login, exchanges it with an external service for a token, and hands the token back to client-go.
Why this beats a static token
Compare it with the alternatives the same page describes. A static token file is a bearer token that stays valid until someone removes it. A client certificate that has been issued remains valid until it expires. The docs also note that with an OpenID Connect identity token, you should treat it like a certificate that cannot be revoked, so it should be short-lived, only a few minutes.
With a plugin, your identity provider issues and refreshes credentials. Offboarding becomes a matter of disabling the person at the source, not hunting for copies of a kubeconfig.
Limits to understand
The docs say almost all credential plugin use cases need a server side component that supports the webhook token authenticator, to interpret what the plugin produces. So this is something your platform team sets up, not a switch you flip alone. It also says earlier versions of kubectl had built-in support for authenticating to AKS and GKE, but that is no longer present, so managed clusters typically give you a separate plugin or command.
What to do on your team
Ask your cluster owners how developers are meant to authenticate. If the answer is a shared kubeconfig with an embedded token, propose moving to a plugin backed by your identity provider. Meanwhile, keep kubeconfig files out of repositories, set their permissions to your user only, and review which clusters each file reaches.
Where Safeguard fits
Safeguard works on the dependency and code side of your software: SBOM and dependency scanning, reachability analysis and policy gates. It does not store or manage credentials, so keep using your password manager, secrets manager or cloud identity for that. You can run a free scan of a project at gold.safeguard.sh/scan.
Quick check
Does the plugin store the token in kubeconfig?
In the docs' model, kubeconfig names a command and the plugin returns credentials when needed. Behaviour such as caching depends on the plugin.
Can I use it without server changes?
The docs say most use cases need a server side component with webhook token authentication support.
What can a plugin return?
A token, or a PEM encoded client certificate and key, per the documentation.
Sources
Last reviewed: 19 October 2026.
