BastionZero has been deliberately designed to work with ephemeral infrastructure. When we say ephemeral infrastructure, we mean compute resources that are created dynamically and destroyed as needed, rather than being persistent and long-lived. Great examples of ephemeral infrastructure include servers in an autoscaling group, containers in a Kubernetes cluster, or infrastructure that gets spun down at night and spun back up in the morning. In other words, we are talking about the “cattle” in the “pets vs cattle” analogy.
Ephemeral infrastructure has become the cornerstone of modern DevOps practices. Ephemeral infrastructure is reproducible – it is easy to deploy, scale and update. It also improves security by eliminating compromising material that an adversary may have installed on your server when that server is terminated. Ephemeral infrastructure can also reduce overall spend because you no longer have to pay for compute cycles you are not using.
Despite this, even with ephemeral infrastructure, your engineering and DevOps teams may still require access to infrastructure to support debugging and forensics. Teams need to be able to work through production issues, react to security events, or observe the infrastructure as it interacts with production workloads. Luckily, you can use BastionZero for this.
Let me take you through the details.
Server Access. Let’s start with using BastionZero with ephemeral servers. BastionZero’s phone-home architecture makes this easy. Simply bake the bzero agent into your server (using your preferred CI/CD tool) and have the agent autodiscover itself to the BastionZero SaaS. The newly spun-up server will be automatically added to your organization's list of available targets.
Next, we need to make sure your BastionZero access policies apply to the new server. We cannot be writing new policies for every newly spun-up server so this is where environments come into play. An environment is just a way of tagging or grouping machines. If your new server is tagged with an environment (e.g., “Linode”) either at the time of registration or manually via the web app, and there is policy associated with that environment (e.g., “All members of the Product group have root access to SSH targets in environment Linode”), then that policy automatically applies to the new server. And that’s all you need to support ephemeral servers.
Database Access. Next, let’s cover database access. BastionZero treats each database as a virtual target – a target that sits behind an agent that is deployed on a server or a Kubernetes cluster. The agent acts as a proxy to the virtual target. But what happens if that server or cluster hosting the proxy agent is spun down as part of an ephemeral infrastructure strategy? To account for this, BastionZero supports using environments (rather than an explicitly named agent) as proxies. That way, as long as there is at least one agent online in the environment, then that server or cluster can be the proxy to the database.
Using environments as proxies applies to any virtual target you set up in BastionZero. We’ve had folks set up virtual targets that tunnel to a variety of databases, rare protocols from the 1980s, and other protocols like VNC.
Kubernetes Access. To set up access to Kubernetes clusters, Helm or YAML is used to deploy a bzero agent in the cluster. The bzero agent then phones home to the BastionZero SaaS and essentially acts as a proxy to the Kubernetes API. Your teams can then use the BastionZero zli (our CLI), kubectl, or other Kubernetes tools like Lens or k9s, to access the cluster.
In a Kubernetes cluster, containers and pods are ephemeral and can be evicted for a variety of reasons. This could create a problem for access if the evicted pod is the one hosting the bzero agent. Fortunately, our “multi-replica support for k8s” feature addresses this problem by allowing you to deploy multiple copies of the bzero agent in the cluster, any one of which can be a proxy. That way, your connections to your Kubernetes cluster remain unaffected by any pod evictions or cluster upgrades that are part of your ephemeral infrastructure strategy.
Infrastructure As Code. An ephemeral infrastructure strategy usually relies on some flavor of Infrastructure as Code (IaC) strategy. Fortunately, BastionZero is easy to integrate into your IaC tooling. We support deploying agents via a variety of IaC tools including Terraform, Ansible, yum, apt, Helm, YAML and others.
Plus, our product is API-driven, meaning that all administrative features available in our web app are also available via our API or Go SDK. Better yet, you can declaratively administrate BastionZero via our full Terraform provider.
That’s it! We’ve covered the key approaches for using BastionZero with ephemeral infrastructure. Reach out to our sales team if you’d like to chat more about how this architecture could be helpful to improve the security of your infrastructure.
See BastionZero in Action
BastionZero connects teams to resources and requires no additional infrastructure to deploy or manage. It is the first—and only—cloud-native solution for trustless access providing multi-root authentication while maintaining zero entitlements to your systems.
With BastionZero, you can reclaim your architecture from over-privileged third parties and ensure that the right people have access to the right resources at just the right time—every time.
Schedule a demo now to see how you can trust less and access more with BastionZero.
