December 7, 2021

BastionZero Manifesto

Sharon Goldberg, PhD.

CEO of BastionZero

Hello World 

As the new kid in the infrastructure and remote access space, we wanted to take a moment to introduce ourselves. We are a group of cryptography PhDs, engineering leaders, and infrastructure experts and enthusiasts who think the remote access industry needs some shaking up. In fact, we believe everything about infrastructure and remote access needs to be simpler and more secure.

We understand your engineers inevitably want access to your infrastructure. They demand the ability to shell into EC2 instances, use kubectl to make changes to a cluster, or jump into a database to run analyses or look at records. 

You can try to stop them sometimes, but at the end of the day, your business requires you to provide access to infrastructure and manage the risks.

Your trepidation is both real and valid.

That’s why we built BastionZero.

We promise to be your partner in reducing risk. Because at the end of the day, we both want the same thing — to provide your users with exceptionally secure remote access to your infrastructure. 

Keep reading to learn how we’ll do this together.

How did we get here?

The fear is real. Speak with any security engineer or anyone responsible for managing infrastructure and remote access, and if they're honest, they’ll tell you there is a lot to be afraid of. Here’s a few scenarios that we’ve seen first hand...

Mistakes. The most common mistake is giving too many engineers too much access to your infrastructure. Next thing you know, production is broken because someone shells into a server that they should not be touching in the first place. And, if our own experience tells us anything, the access logs are likely patchy or hard to find, making it hard to figure out who’s responsible for that irresponsible “update.” 

Attacks. Starting off, open ports are a favorite attack vector for ransomware propagation. Next, if you hand out VPN and SSH credentials, you need to ensure your engineers don’t lose them, leak them, or even mistakenly share them with an adversary as well. Of course, you don’t want your kubernetes APIs on the public internet and your internal websites accessible to all either. And finally, you certainly don’t want an adversary to attack a bastion host your predecessor installed three years back and no one ever managed to patch.

Compliance. Your customers understand these risks as well. Which is why providing evidence that the the right people in your organization have access to roles and targets is a key part of many compliance frameworks, including SOC2, PCI and others. 

Even sales teams are starting to include this as part of their standard procedure, expecting answers to customer questionnaires that dig into how you manage access. And you certainly don’t want to spend hours gathering evidence for your auditors, only to be embarrassed by your answers (or in some cases lack of).

So we set out to build something with better security and less complexity.

Simplicity should be the goal

Tell us if any of these sound familiar...

  • You have tens of engineers connecting to your kubernetes API through a variety of different roles (or maybe just one over-privileged role!).
  • You have home-grown bastion hosts to manage. 
  • You have a VPN, along with user SSH keys that are dropped on different targets using a homegrown CICD process. 
  • You have stitched together your own access system using tools offered by your cloud provider or other third party products (most likely duplicated across environments). 

Just looking at the examples above, to say there are lots of ways to provide access to infrastructure, and as many different types of infrastructure that engineers need access to, is an understatement. And with each approach or scenario more complexity is introduced.

Of course, all of this complexity is hard to manage, and often leads to bugs and security risks. Not to mention, it can be embarrassing to present to customers and auditors as well.

We’ve faced these challenges ourselves. And this is why we built BastionZero with simplicity in mind. This means…

  • You shouldn’t have to maintain long-lived credentials for each of your users and targets. 
  • You shouldn’t have to disrupt your engineers’ workflows. 
  • You shouldn’t have to patch or maintain bastions, jumphosts or VPNs across all your environments.

Remote access a cloud service 

BastionZero is a cloud service offering remote access to all of your targets (servers, containers, clusters, web applications and DBs) across all of your cloud and on-prem environments. Essentially a unified platform for infrastructure access. 

We prioritize making our service easy to deploy into your infrastructure and easy to integrate into your engineers workflows. We won’t ask you to self-host or maintain redundant proxies in each of your environments. We won’t ask you to take six months to roll out an infrastructure access platform across your organization.

It also means you save hours managing all those annoying tasks, like handing out keys and credentials, manually on-boarding and off-boarding engineers as they enter or leave the organization, or searching for bespoke evidence to show auditors and customers that the right people had access.

Zero Trust, not just a buzzword anymore 

 “If you want to allow engineers to access your infrastructure, you really should be doing it in a zero-trust way.” Anonymous

Right. Like us, you’ve heard that one a lot.

OK, so let’s talk about what zero trust really is. It’s a buzzword. Everyone uses it. 

However, regardless of said buzzworthiness, it’s still guiding the way most of us think about cloud security. And that’s ok.

In this industry, zero trust usually means “don’t trust your users with long-lived credentials.” This makes sense. Long lived credentials can get stolen. Users can walk off with credentials, or mistakenly leak them to adversaries. If we want to keep our cloud systems safe, we shouldn’t have long-lived credentials lying around all over the place. 

So how do we get rid of long lived credentials? 

Well here’s where we go from “best practice recommendation” to “checking the box that says zero trust” without actually providing zero trust.

In fact, what usually happens with zero-trust systems is: we put in some highly-privileged authority that issues short-lived credentials to our users. For example, we tie everything to an SSO (pick your favorite: Active Directory, Okta, Gsuite, AWS SSO, etc etc), or we use a certificate authority that issues short-lived certificates to our users.

And this approach is great for removing trust from our users. But have we really dropped trust to zero?

Unfortunately not. 

By putting in a highly-privileged authority that completely controls who gets access to what, we’ve put 100% of our trust into that authority. That’s not zero. 

Making things worse, adversaries know that too. Over-privileged certificate authorities have been a juicy target for attacks for decades, and attackers are starting to clue into and exploit vulnerabilities in SSO providers.

We believe there is a way for “zero trust” to really mean zero. And that’s the premise we’ve built the BastionZero security model on.

A better zero-trust security model

At BastionZero, many of us come from the world of crypto (where crypto means cryptography!), and where minimizing trust in authorities is a simple, achievable and well understood goal. 

So we started with a simple focus: don’t build systems that put all their trust in a single over-privileged authority. 

Instead, we developed a cryptographic security model that splits trust between two different authorities. 

One of these authorities is our BastionZero cloud service. The other is your SSO provider. 

What does this actually mean? 

It means that if one of the authorities is compromised, your targets are still secure because the other authority protects them. And it's unlikely that someone will compromise our cloud service AND your SSO provider at the same time. 

Not only does this provide great odds for protecting your infrastructure, it also means you can finally (truly) provide a zero-trust approach to infrastructure access in your organization.

We don’t have (or want) privileged access 

When we say, don’t give away all your keys to your kingdom, we mean it. BastionZero is a cloud service, which makes it easy to deploy, integrate and maintain. 

Practically speaking, we understand you also don’t want to worry about our cloud service being compromised either. The good news is that we’ve gone to great lengths to ensure that even if BastionZero’s cloud service was compromised, your targets remain secure.

Our cloud service does not have (or want!) privileged access to your infrastructure targets. 

Instead, our cryptographic remote access protocol requires that targets only provide access to users that are authorized by your SSO provider. That means that no one has access to your targets without the permission of a valid user in your organization, not even our cloud service.

So you can rest easy using our cloud service without worrying that we’ll become a single point of compromise for your organization. 

And, if you’d really like to get into the technical details, we’ve written a white paper on our security protocol: the Multi Root Zero Trust Access Protocol (MrZap). We believe our security model is at the center of modern infrastructure access management.

Connect with our OpenPubkey experts!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
BastionZero Manifesto

Cloud-agnostic policy-based access 

No, you shouldn’t have to mess with IAM roles on different clouds and different accounts. 

And no, you shouldn’t have to jump through settings screens and configuration hoops to control who accesses what in your infrastructure. 

BastionZero is built on top of the Open Policy Agent (OPA) to provide a universal policy language that allows you to precisely control which user gets access to which account/role on which set of targets, in any cloud or account.

Visibility matters

Most of today’s solutions offer overly verbose and opaque logs that translate to hours of evidence gathering during a compliance audit and hours of investigation when there’s an incident. And if it’s truly a case of an outage or a malicious actor in your infrastructure, that’s time you don’t have.

Whether you’re looking for an opportunity to offer a training moment for your users, actively investigating as part of a war room activity, or conducting a postmortem after a realized attack --- the getting to what was done, and by whom, as quickly as possible is the critical differentiator in preventing further issues.

Logs should be at the forefront of any solution or approach, and that’s why we built BastionZero with centralized logs that include:

  • Who accessed what target under which role or account. (e.g. User @goldbe ran the ‘rm -rf’ command on target centos-q1 as the centos user) 
  • What commands they ran on the target (whether in a database, k8s API or kubectl exec) 
  • Logs that can be pulled in JSON from our API and sent to any SIEM
  • The ability to watch a session recording of exactly who commands someone ran on a Linux targets

We like to think of it as root cause analysis, compliance and evidence gathering made easy.

Close your ports. Autodiscover your targets.

“No more open ports.”

We’re certain this is something your organization would love to hear. And, if you’re charged with building a modern, highly-secure approach to infrastructure access, it should be at the top of your list.

Not only because allowing inbound connections to your cloud infrastructure is incredibly risky; it’s also become passé.

So, you don’t need us to tell you it’s much safer to close all your ports and have targets initiate connections themselves. 

But that can be easier said than done, and from home-grown solutions to off-the-shelf products this can be both a challenge and a time sink.

With BastionZero, targets spin up and phone home to BastionZero’s cloud service using a websocket over TLS. 

This allows the target to connect to BastionZero over a secure connection, without a VPN and even if it's on a private IP.

And to make it even easier, this “phone home” architecture also allows for autodiscovery of your targets, and eliminates the need for manual configuration of your targets.


That’s our vision. To lead the remote access industry via a cloud service that eliminates complexity and provides exceptional security for zero-trust access to your infrastructure. We know this industry needs a shake up, and we’re ready and willing to deliver. Watch out world, there’s some new kids on the block. 

By Sharon Goldberg, PhD.

CEO of BastionZero

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.

Sign up for the BastionZero newsletter

We talk about zero trust, remote access, threat intel, and more!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Future-proof your cloud security strategy

Try BastionZero for free today and see why fast-growing companies trust us over any other identity provider.