Readit NewsShould someone in another country be able to publish your personal secrets? Sure if its North Korea you can't do much but a organization in a friendly country should not be allowed to do so esp if they're important nationally classified material.
So I wrote this https://github.com/icy/gk8s#seriously-why-dont-just-use-kube... It doesn't come with any autocompletion by default, but it's a robust way to deal with multiple clusters. Hope this helps.
Edit: Fix typo err0rs
PS1='\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]\[\033[01;33m\] [`kubectl config current-context| rev | cut -d_ -f1 | rev`] \[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\] $ 'That said, going Multi-Cloud is indeed unavoidable in a growing number of settings. So, instead of looking at it as a source of troubles, it can be leveraged as a way to extract the best features out of each provider, to avoid lock-in wherever it makes business sense and to minimize costs by distributing workloads accordingly. That introduces new issues regarding access control, cost analysis, auditing and governance which are best managed by a Multi-Cloud Management Platform.
If you're looking for such a tool check out https://mist.io
It's an open source CMP that supports most popular public & private clouds, as well as Hypervisors and container hosts. It takes care of provisioning, monitoring, RBAC, cost analysis and automation/orchestration. It can also be used to deploy Kubernetes clusters on any supported cloud.
Disclaimer: I'm one of the founders.
https://docs.mist.io/article/119-kubernetes-getting-started-...
Disclosure: I'm one of the founders
Mist.io is a cloud management platform that uses Apache libcloud under the hood. It provides a REST API & a Web UI that can be used for creating, rebooting & destroying machines, but also for tagging, monitoring, alerting, running scripts, orchestrating complex deployments, visualizing spending, configuring access policies, auditing & more.
For that, you should consider setting up multiple accounts to isolate those services from the portable ones.
Disclosure: I'm one of the founders.
We built this because we’re seeing a shift from "chatting with agents" to event-driven flows (agents reacting to webhooks, PRs, or tickets in the background).
The problem we hit was responsibility. An agent can technically execute a stripe.refund tool call, but it cannot weigh the consequences of a $50 refund vs. a $5,000 refund. It lacks the context of risk.
We built the proxy to bridge that gap. It lets the agent run autonomously 99% of the time, but forces a "hardware interrupt" (human check) when the stakes get high. We handle the state management of pausing that headless workflow so you don't have to build custom polling logic into every bot.