ed_mercer
3 hours ago
I got burned by this recently and came to the conclusion that the concept of a current context is evil. Now I always specify —-context when running kubectl commands.
3 hours ago
I got burned by this recently and came to the conclusion that the concept of a current context is evil. Now I always specify —-context when running kubectl commands.
2 hours ago
Have been burnt by this, I have to deal with close to 8 clusters and it is very easy to make a mistake.
Would highly recommend kubie, it allows you to switch and shows you the name of the cluster in the prompt. It's probably a more visual way of solving the same problem.
2 hours ago
I came up with a simpler solution that keeps kube contexts separated per terminal.
5 hours ago
haha
i added the following to my bashrc a few days ago for similar reasons; this forces me to be explicit about the cluster; now i mess up the wrong namespace instead :)
if [[ -e "/opt/homebrew/bin/kubectl" ]]; then
/opt/homebrew/bin/kubectl config unset current-context >/dev/null
fi
2 hours ago
Someone here showed me this cool technique with `fzf`:
#!/usr/bin/env bash
set -e
context=$(kubectl config get-contexts | awk '{print $2;}' | grep -v NAME | fzf --preview 'kubectl config use-context {} && kubectl get namespaces')
kubectl config use-context $context
You get a two-pane window with the context on the left and the namespaces on the right. That's all I need to find what I'm looking at. It's destructive, though.3 days ago
This seems good, but can it also be done via ACLs in vanilla Kubernetes?
3 days ago
Thanks Robert! Yes, you can achieve this with ACLs in Kubernetes, but it requires setting up multiple Roles and contexts. Even then, you might accidentally switch to a higher-permission Role and accidentally run a risky command, thinking you're in a different cluster or using a low-permission user.
Kubesafe is just an extra safety net to prevent those kind of accidents :)
2 days ago
That makes sense - thanks for the reply.
3 days ago
I am not trying to shit on this, sorry - but can't you achieve the same thing with rudimentary automation, and barring that, rudimentary scripting? This seems to just be adding y/n prompts to certain contexts. How's that different than a bash wrapper script that does something like this?
context=$(grep "current-context:" ~/.kube/config | grep "*prod*")
if [[ -z ${context} ]]
then # do the command
else # do a y/n prompt
fi
Am I missing something?
3 days ago
Thanks for the feedback John! You're right, that's pretty much it :)
I developed kubesafe because (1) I was tired of tinkering with shell aliases and scripts (especially when I wanted to define protected commands) and (2) I needed something that worked smoothly with all Kubernetes tools like kubectl, helm, kubecolor, etc.
Kubesafe is just a convenient way to manage protected commands and contexts. Nothing too fancy!
Btw - I also found a kubectl plugin written in Bash that’s similar to what you mentioned, in case you're interested: https://github.com/jordanwilson230/kubectl-plugins/blob/krew...
3 days ago
thanks for the explanation, I like the idea
3 days ago
You're welcome! And thanks again for the feedback!