Add '--as-service-account' flag to `kubectl auth can-i`

[riita10069]

What would you like to be added:

$ kubectl auth can-i get pod  --as-sa (NAMESPACE):(SERVICEACCOUNT)
yes

Why is this needed:

Commands like the following will fail

$ kubectl auth can-i get pod  --as (NAMESPACE):(SERVICEACCOUNT)
no

When specifying Service Account with --as, it must be specified as system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT).

$ kubectl auth can-i get pod  --as system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)
no

I've done it this way before, but find it hard to remember and hard to use.

It should be very simple as it just adds system:serviceaccount: to the string. If this PR is triaged, I'm willing to contribute as much as possible.

[k8s-ci-robot]

@riita10069: 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/test-infra repository.

[riita10069]

/sig cli

[Ithrael]

/assign

[Ithrael]

I agree with you

[ardaguclu]

Thanks for opening this issue!

Introducing new flag needs strong reasoning because it also brings it's own extra burdens in terms of maintainability and user adoption.

--as flag is kubectl wide flag and can be used for all commands and IMHO, instead introducing a new flag just for short cut, it is better to use --as system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT) because this is relevant for all commands.

I'd prefer closing this issue.

[riita10069]

Your argument is understandable.Also, I don't see it as a super-critical issue. Let me write a little more about what I felt.

User, ServiceAccount and Group are recognized as different entitie from ClusterRoleBinding and RoleBinding. Even kubectl supports commands like:

kubectl create rolebinding NAME --role=NAME [--user=username] [--group=(groupname)] [--serviceaccount=(namespace):(serviceaccountname)]

Therefore it was difficult for us to know how to evaluate a ServiceAccount as a Username. (i.e. We don't know it's system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT). Well, it's written in the docs.)

Why treat only the can-i command the same way about them?

[ardaguclu]

I totally understand the inconvenience in here. User needs to know when service account will be passed to as flag, it should include system:serviceaccount: prefix.

However, if we introduce such shortcuts, doesn't it hurt the learning process of the real as command's usage with service account?. Because we just make it easy for can-i command but still there are a lot of commands.

I'm closing this issue and please feel free to re-open it if you think that I'm missing something.

/close

[k8s-ci-robot]

@ardaguclu: Closing this issue.

In response to this:

I totally understand the inconvenience in here. User needs to know when service account will be passed to as flag, it should include system:serviceaccount: prefix.

However, if we introduce such shortcuts, doesn't it hurt the learning process of the real as command's usage with service account?. Because we just make it easy for can-i command but still there are a lot of commands.

I'm closing this issue and please feel free to re-open it if you think that I'm missing something.

/close

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/test-infra repository.