Example correction in the documentation: "kubectl auth can-i ... --as ..." about website HOT 9 CLOSED

The existing format should work the same as the alternates. Can you share what problem you are seeing with it?

from website.

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, 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.

from website.

/language en

from website.

/triage needs-information

@czavieh Would you be able to share the information requested in #45728 (comment)

from website.

/priority awaiting-more-evidence

from website.

I tried to use the format as suggested in the documentation, --as=system:serviceaccount:dev:foo cli didn't accept it. However when I put the value in the double quotation marks, cli accepted:
--as="system:serviceaccount:dev:foo"
I didn't have any issue with this format(not using =) : --as system:serviceaccount:dev:foo

So I am confused too. This happened the day I reported. I delete that environment and don't have access to it to take screenshot. I don't have any explanation and if I am the only person who has ever reported this, we can close the ticket and next time I encounter this issue, I will document it with details and then report it. Thank you for prompt response.

from website.

@czavieh The command is working perfectly the same as given in the doc and the suggested one. --as=system:serviceaccount:dev:foo is not an intentional behaviour you can use either of the command in some case the command in "" will be treated as single argument which is correct and intended behaviour.

So both the command are working fine and are correct.

from website.

So for now i am closing this issue you can reopen it or raise the new issue in case you encounter the error.

/close

from website.

@niranjandarshann: Closing this issue.

from website.