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.

[ardaguclu]

/kind support /remove-kind feature

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[mpuckett159]

/close I am going to close this if further support or development is desired please re-open

[k8s-ci-robot]

@mpuckett159: Closing this issue.

In response to this:

/close I am going to close this if further support or development is desired please re-open

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.