Recent submissions

Comment · 2 years ago
Absolutely! kubesafe is simply a wrapper, so you can use it with any Kubernetes tool by passing the tool as the first argument to kubesafe.

Example with kubecolor:

`kubesafe kubecolor get pods --all-namespaces`

Comment · 2 years ago
I think it’s a tradeoff between safety and speed. Having only the CI/CD with production access can significantly slow you down, especially in the early stages when you’re focused on the product and still building out your tooling/infrastructure.
Comment · 2 years ago
Cool project, I didn't know it. I love the idea, thanks for sharing it!
Comment · 2 years ago
I also have it in my zsh config, but that didn’t stop me from screwing up in the past. Having an active confirmation prompt for potentially risky commands is what works best for me
Comment · 2 years ago
Got burned too, we've all been there I guess :)

I also tried to avoid current context initially, but it just slowed me down. Switching between clusters is so much easier with the current context and kubectx.

That’s why I built kubesafe. In this way I can keep using the current context without worrying about screwing up. If I accidentally target the wrong context, at least I get a warning before executing the command.

The only hassle now is remembering to add new prod contexts to the safe list, but that’s about to change with regex support coming soon :)

Comment · 2 years ago
You're welcome! And thanks again for the feedback!
Comment · 2 years 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 :)

Comment · 2 years ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton