BastionZero's Architecture
BastionZero was built with security at the forefront. Our MrZAP protocol discussed here was designed specifically so you could outsource your bastion host without giving up control of your infrastructure. The technology reduces your risk of compromise while providing simple-to-implement-and-read access policies and audit logs for your compliance needs.
With BastionZero there are no open ports, no need for self-hosted bastions, and more importantly, no single point of compromise as two independent roots of trust control access -- BastionZero & your identity provider (IdP).
The next section will describe roles and responsibilites as well as common terms of the architecture.

How BastionZero Works

An end user interacts with BastionZero using either the web app or the zli client.
To connect to a target, the user must first authenticate. To do this, the user performs an SSO to her organization’s IdP, followed by an MFA to the BastionZero cloud service. (BastionZero currently supports MFA via the TOTP protocol.) The IdP and the BastionZero cloud service act as independent roots-of-trust that control access to targets. This ensures that a compromise of the BastionZero cloud service does not lead to a compromise of your infrastructure targets. (Learn more about the BastionZero security model here.)
Once the user has authenticated, they can request connections to targets and then execute commands on these targets. These requests arrive at the BastionZero cloud service, where they are logged and evaluated by a policy engine that either drops the request (if the user does not have a valid policy to access the target) or passes the request on to the target (if the user does have a valid policy to access the target). All actions (and thus all APIs) in the BastionZero service are subject to this policy evaluation and logging.
A target is a destination such as a VM, server, k8s cluster, web app, or database. The target is responsible for enforcing the policy action. BastionZero clients support connecting to and interacting with targets via shells, SSH including SSH tunnels, secure copy, k8s APIs, database clients, and web apps (RESTful applications).
Clients and targets both connect to the BastionZero cloud service via websockets over TLS. Because both clients and targets phone home to the BastionZero cloud service, both clients and targets can be invisible to the public Internet (i.e., remain on on private IPs or behind a NAT), even without a VPN.
The next section will describe roles and responsibilites as well as common terms of the architecture.
Last modified 17d ago
Copy link