What causes "auth plugin not yet supported by ToRESTConfig" in kubernetes/kops?

auth plugin not yet supported by ToRESTConfig

Error message

auth plugin not yet supported by ToRESTConfig

What it means

ToRESTConfig builds a rest.Config directly from stored TLS/host fields instead of going through clientcmd. Exec-based credential plugins (auth plugins) require the client-go auth loading machinery, which this method does not implement, so it refuses to produce a config that would silently lack credentials. It is a deliberate feature gap, not a data problem.

Source

Thrown at pkg/kubeconfig/kubecfg_builder.go:222

	if err := clientcmd.ModifyConfig(configAccess, *config, true); err != nil {
		return err
	}

	fmt.Printf("kOps has set your kubectl context to %s\n", b.Context)
	return nil
}

func (b *KubeconfigBuilder) ToRESTConfig() (*rest.Config, error) {
	restConfig := &rest.Config{}

	restConfig.Host = b.Server
	restConfig.TLSClientConfig.CAData = b.CACerts
	restConfig.TLSClientConfig.ServerName = b.TLSServerName

	usingAuthPlugin := len(b.AuthenticationExec) != 0
	if usingAuthPlugin {
		return nil, fmt.Errorf("auth plugin not yet supported by ToRESTConfig")
	}

	restConfig.CertData = b.ClientCert
	restConfig.KeyData = b.ClientKey

	return restConfig, nil
}

View on GitHub (pinned to 4c8573c808)

Solutions

Use clientcmd's clientconfig (e.g. clientcmd.NewNonInteractiveDeferredLoadingClientConfig(...).ClientConfig()) which supports exec plugins
Clear b.AuthenticationExec and set static credentials (ClientCert/ClientKey or bearer token) if plugin auth is unnecessary
If you control the code, implement exec-plugin support by wiring rest.Config.ExecProvider from b.AuthenticationExec
Fall back to shelling out through the generated kubeconfig with kubectl

Example fix

// before
builder.AuthenticationExec = []string{"aws", "eks", "get-token", ...}
restConfig, err := builder.ToRESTConfig() // error
// after: use clientcmd which resolves the exec plugin
loadingRules := &clientcmd.ClientConfigLoadingRules{ExplicitPath: kubeconfigPath}
restConfig, err := clientcmd.NewNonInteractiveDeferredLoadingClientConfig(loadingRules, nil).ClientConfig()

Defensive patterns

Strategy: fallback

Validate before calling

if len(builder.AuthenticationExec) != 0 {
	// use clientcmd path instead of builder.ToRESTConfig()
}

Type guard

func supportsToRESTConfig(b *kubeconfig.KubeconfigBuilder) bool {
	return len(b.AuthenticationExec) == 0
}

Try / catch

restConfig, err := builder.ToRESTConfig()
if err != nil && strings.Contains(err.Error(), "auth plugin not yet supported") {
	restConfig, err = clientcmd.NewNonInteractiveDeferredLoadingClientConfig(
		&clientcmd.ClientConfigLoadingRules{ExplicitPath: kubeconfigPath}, nil).ClientConfig()
}

Prevention

Prefer clientcmd.ClientConfig() when exec auth plugins may be in use
Check builder.AuthenticationExec before calling ToRESTConfig
Keep static client certs if you need programmatic REST access
Track upstream kOps for exec-plugin support in ToRESTConfig

When it happens

Trigger: Calling KubeconfigBuilder.ToRESTConfig() when b.AuthenticationExec is non-empty (builder was populated from a kubeconfig user that uses an exec auth plugin, e.g. aws-iam-authenticator or gke-gcloud-auth-plugin).

Common situations: Programmatically building a REST client for a cluster whose kubeconfig relies on an exec credential plugin; EKS/GKE/AWS-auth based clusters.

Related errors

AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05). Data as JSON: /api/errors/f67555677a720264. Report an issue: GitHub.