highb
commented
3 years ago I can provide a user story of sorts around this. Our access pattern for developers on our k8s clusters is going to be that we provide k8s RBAC view access by default with no request needed, and folks can request exec (1) permissions for staging or production. With that context, I can see a developer having the following workflow experience:
1) Using tsh day-to-day in debugging issues with no requests needed.
2) There is an incident in the staging environment that the dev is called in to debug, so they go and request exec on staging via tsh --request-roles staging-exec. They must wait for someone to review the Jira ticket created by the request. (2)
3) The request is approved, and they debug the issue on staging successfully. But... the issue inevitably shows up again when the deploy to prod occurs so they must request access again, with tsh --request-roles prod-exec. Wait for approval, debug issue, fix it, everything is copacetic.
4) For whatever reason, there is now yet another issue on staging and so the dev would like to switch back to the staging-exec role. From what I can tell from the CLI help and docs, there is no way to re-assume this role other than to tsh --request-roles staging-exec yet again, and get approved, yet again. This is a lot of churn on both the dev and approver sides.
Ideal State
The developer would request staging-exec and then prod-exec and then either be able to re-assume those roles freely for as long as their access is valid, or would have both of those roles added to their cert for every future connection until the roles expire.
Footnotes
(1) No standard k8s RBAC for this, but it's essentially view + exec/view logs on pods
(2) There is a problem here. What happens if their network connection is interrupted or the otherwise disrupted in the interim? Could they get into a situation where they would have to make another request and end up confusing the reviewers because they have to approve the same request for the dev again?
jeffjen
pschisa
programmerq
What
Allow a user to assume role in the CLI like in the web from a approved access request. A user can assume a role dynamically in the web console if they have been approved. In the CLI a user has to request their access workflow request again if they logged into another machine or their request was interrupted on their machine.
How
Provide a new command assume that allows for assuming a approved request.
Why
Reduces the need to request role(s) again after the already approved.