Open jonmoter opened 4 years ago
This is a great idea. The prompt could even be changed to display the user in this mode [context|namespace|@user]
.
Do you intend on working on this feature? No pressure to do it, just want to know who's working on what.
For now I just wanted to write down the idea before it slipped out of my head.
At the moment I'm pretty busy with work/family/life, so I can't commit to executing in any particular amount of time. But if I have some extra time to hack up a PR, I'll do so.
It seems like a simple enough change. I can write it in a branch so you can test. I don't have this kind of role configured in my clusters, I'll have to setup it up if I want to test it out.
Is there an update on this feature? Recently ran into the need to use impersonations and I think the way you guys have outlined it above would be a great addition to kubie.
I'm not really working on new features for kubie at the moment. I would merge & review PRs for new features but I don't really have the time or inclination to develop new stuff.
Really appreciate the work so far! If I find some time myself I'd love to learn some Rust and make a contribution to the project.
Normally when I use kubectl to interact with shared/production clusters, I use credentials for a user with read-only permissions. But the user has the ability to impersonate a user with admin-level permissions. So if I need to make a change, I can run something like:
It's kindof like using
sudo
for executing commands with higher permissions.It would be useful for me to be able to run something like this:
That would give me a shell where the temporary kubeconfig file would have:
Then I could run a few commands with those credentials, and then exit out of the shell.
This would also be useful for CLI tools like
istioctl
that do not support passing--as
as a command-line flag.