Last week, we blogged about a high-availability feature for Kubernetes (“multi-replica support for k8s”), that ensures your cluster is accessible even if a bzero agent is inadvertently evicted from your cluster. Specifically, the feature supports multiple replicas of the bzero agent on a single cluster. Today, we continue our series on the high-availability features of BastionZero with a similar feature for databases and other virtual targets.
We call this feature “use environments as proxy targets.” The feature debuted in November, and it’s time we highlight how powerful it can be for your organization.
BastionZero has a concept called virtual targets. Vanilla BastionZero uses agents -- use our Linux agent to access a Linux target, our Windows agent to access a Windows target, and our bzero container (replicas) to access a Kubernetes cluster. But we also support access to databases, and you can’t run an agent on the most popular databases (think RDS, MongoAtlas, GCP Cloud SQL, and other databases that are not self-hosted). So what do we do?
BastionZero treats each database as a virtual target -- a target that sits behind an agent that is deployed elsewhere (e.g., on a server or a cluster). The agent acts as a proxy to the virtual target, as shown in the figure above. As long as the proxy agent has access to the virtual target (e.g., database), users can access the virtual target through the proxy agent.
As an example, if you deploy a bzero agent (or three) on your Kubernetes cluster you can also use that agent to access a database like RDS, Google Cloud SQL, etc. In this setting, you get high-availability for your database because we support multiple agents in the set of proxy targets (aka, the feature we blogged about last week).
But what if you have a virtual target (e.g., RDS) that is accessible via an agent deployed on a server (e.g., an EC2 instance), rather than a Kubernetes cluster? Well, that’s where today’s highlighted feature enters the chat. Instead of using a single agent running on a single target (e.g., “my-db-proxy”) to proxy the database, you could use a set of agents, each running on a different target, to proxy to the database. When trying to connect to the database, BastionZero selects a proxy target from the set based on least load. We define load in this context to be the number of open connections associated with the proxy target.
We implement this feature using BastionZero’s notion of environments. An environment is just a way of tagging or grouping machines. So, to provide high-availability for your virtual target, you would use an environment (i.e., a set of agents) as the proxy, rather than using a single agent as the proxy.
Another neat thing about this feature is that it enables fully-ephemeral infrastructure. To understand why, imagine you have servers that are spun down at the end of the day and later replaced by fresh servers. These fresh servers that spin up may have fresh hostnames, but you’ll ensure that they run bzero agents and are tagged with the same BastionZero environment as their predecessor servers. Now, if you use the BastionZero environment as the proxy for your database, that database will still be accessible via the newly spun up server. Voila, ephemeral infrastructure! (We didn’t make this scenario up, by the way. Our customers are currently doing this.)
You can find instructions for supporting access to your databases here with details on how to set up environments as proxy targets here. Get in touch with our sales team if you’d like to chat more about how BastionZero can help support access to managed databases and ephemeral infrastructure with high availability!
