Only prompt for specific contexts

[theelderbeever]

What would you like to be added:

This specifically pertains to the situation where one would alias kubectl=kubectl confirm however, it would be great if this could have a configuration available to only prompt when running against specific cluster contexts or for specific subcommands.

Why is this needed:
This could help protect only commands that modify the cluster and only do it on clusters that matter. Consider the situation where you might have a dev cluster and a production cluster in your contexts. Generally, I am okay with firing off on prompted commands against the dev cluster because I am usually exploring or testing changes to the cluster and like to move fast. However, sometimes I have my context set to prod and this is really when I want to be prompted. By making the prompts context specific it can help avoid the habit of just slamming yes into the prompt.

Likewise with specific subcommands. I don't really need to confirm that I want to run a kubectl get pods however, kubectl delete pods would be valuable to be prompted for.

I would think a small config file mapping context names to commands should be sufficient. If the context is in the file and the command is in the list of prompts then prompt. Otherwise, just passthrough as though it was a vanilla kubectl command.
ie:

prod-context-name:
  command:
    - apply
    - delete
    - rollout

[brianpursley]

I like the idea and understand the use case.

My only concern is whether this might lead to someone being surprised, if they execute kubectl confirm and weren't aware that there is a config file: "I ran kubectl confirm, and it didn't ask me to confirm before I deleted every resource in my namespace".

I feel like anytime someone types kubectl confirm it should always prompt them.

In the case of the alias it is a little different situation because you are not actually typing "confirm". Maybe it could be controlled through command-line flags.

Something like:

alias kubectl=kubectl confirm --confirm-context=prod1,prod2 --confirm-command=apply,delete,patch,replace

or

alias kubectl=kubectl confirm --confirm-exclude-context=dev1,dev2,test1,test2 --confirm-exclude-command=get

Admittedly, this isn't quite as flexible as the config file approach, but would be simpler.

There could be a way to do it through an explicit config file, I guess. Something like this perhaps:

alias kubectl=kubectl confirm --confirm-config=~/.my-confirm-config

[theelderbeever]

@brianpursley No worries. Honestly I just ended up writing my own plugin for the academic exercise. Still has issue with TTY and some apply commands though.

Thanks for the response nonetheless.

https://github.com/theelderbeever/kubectl-guardrails