when you has a default kubeconfig ,using kubectl auth can-i --list --token still get the kubeconfig privielge

[INT2ECALL]

What would you like to be added:
if you are using command like this

kubectl --server=https://192.168.26.65:6443 --insecure-skip-tls-verify --token=$TOKEN auth can-i --list

and you have a default kubeconfig in admin.conf,kubectl also will use the kubeconfig certdata but not use the token，i think if you use --token that mean you want to get is what the token priviege is not the kubeconfig

Why is this needed:
easy and fast to know the what the sa can do

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-sigs/prow repository.

[INT2ECALL]

what i am doing is do some fix in ToRESTConfig function in clientset.go

	if len(clientConfig.BearerToken) > 0 {
		clientConfig.TLSClientConfig.CAData = nil
		clientConfig.TLSClientConfig.KeyData = nil
	}

func (f *MatchVersionFlags) ToRESTConfig() (*rest.Config, error) {
if err := f.checkMatchingServerVersion(); err != nil {
return nil, err
}
clientConfig, err := f.Delegate.ToRESTConfig()

if len(clientConfig.BearerToken) > 0 {
	clientConfig.TLSClientConfig.CAData = nil
	clientConfig.TLSClientConfig.KeyData = nil
}

if err != nil {
	return nil, err
}
// TODO we should not have to do this.  It smacks of something going wrong.
setKubernetesDefaults(clientConfig)
return clientConfig, nil

}

[ardaguclu]

First of all flags should not be located before the command. In that case;

kubectl auth can-i --server=https://192.168.26.65:6443 --insecure-skip-tls-verify --token=$TOKEN **--list**

should be used like this.

and you have a default kubeconfig in admin.conf,kubectl also will use the kubeconfig certdata but not use the token，i think if you use --token that mean you want to get is what the token priviege is not the kubeconfig

Are you saying that when token is used, certdata in kubeconfig should be used?

[INT2ECALL]

i mean ,when you use command

kubectl auth can-i --server=https://192.168.26.65:6443 --insecure-skip-tls-verify --token=$TOKEN **--list**

and if you have kubeconfig ,it also use kubeconfig,not use this token to auth apiserver

[ardaguclu]

I think, running this command with -v=9 shed some light upon what happens.