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 because two independent roots of trust control access -- BastionZero & your SSO provider.

The next section will describe roles and responsibilities 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 SSO provider, followed by an MFA to the BastionZero cloud service. (BastionZero currently supports MFA via the TOTP protocol.) The SSO provider 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 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 responsibilities as well as common terms of the architecture.

Overview

The BastionZero services consists of four main architectural components, clients, a SaaS suite of BastionZero microservices, targets, and your identity provider. Each component has roles and responsibilities in the architecture. All communication among the components is authenticated and authorized as part of the service.

Diagram of the BastionZero architecture overview with three main components, clients, BastionZero microservices, and targets

Let's examine in detail the roles the BastionZero components play in the system architecture.

Clients

BastionZero clients make requests to the BastionZero microservices. There are two clients provided by BastionZero, and both can be used for end user and administrative functions. The clients consist of a web app and zli (command line interface). Both clients utilize BastionZero published REST APIs; thus any developer or organization can build their own BastionZero client. The BastionZero zli client is an open-source project and can be viewed here: BastionZero zli on GitHub.

All BastionZero Clients:

• Authenticate to their organization's SSO provider before any request to BastionZero can be authorized.

• Implement their role and responsibility in the MrZAP architecture.

• Support BastionZero MFA so that a user or application is identified to BastionZero in addition to the organization's SSO provider.

• Create new target connections or can reconnect to existing connections.

• Support secure file transfer.

Web App Client

The web app client has some unique capabilities as described below.

For Administrators

The web app client includes:

• An organization-wide view of command, connection, policy, and audit logs.

• The ability to manage policy, targets, environments, and API keys.

• The abiliy to view and download session recordings.

Note: A user's connection need not be closed to view a session recording. Thus a session recording can be thought of as live view.

zli Client

The zli client extends support to additional capabilities like Kubernetes, SSH tunnels, databases, and web apps. Beyond those functions the zli includes these additional capabilities:

• Supports SSH tunneling as well as local port forwarding to reach any target and use any protocol to reach a target without the need for a VPN gateway.

• Supports quickstart, an easy way to utilize an end user's SSH config file to onboard targets into BastionZero.

BastionZero SaaS

The BastionZero SaaS hosts the core functions of the BastionZero service. These microservices are delivered globally and autoscale up and down with a customer's current demand.

The BastionZero SaaS registers users and targets, manages user and target connections, makes policy decisions, stores and displays events as logs, and hosts the web client application. The BastionZero SaaS hosts all features of the service.

Registration

The BastionZero SaaS supports the target registration process as part of its core responsibility. The registration process starts with an organization's unique registration key(s). These keys identify an organization or a user in an organization and can only be used to request activation tokens from the registration API. An activation token is used to identify and register a target as part of your organization in the BastionZero service.

We recommend storing your API keys including your registration keys in a vault and using our APIs to rotate these keys as an industry best practice.

Connections

Clients and targets establish connections to the BastionZero SaaS. Target connections are managed on a global scale, optimally connected to the nearest supported regional data center. Clients' connections to targets are directed to the region hosting the target only after a policy check results in an approval. All connections are orchestrated by a service running internal to the BastionZero SaaS.

Logging

BastionZero logs many types of events including user shell commands, connections, policy evaluations, k8s APIs, and k8s commands. The BastionZero SaaS will log these events as well as recording a user's shell session (also based on policy). A user can search and copy their command log history for easy retrievel of previous commands. An administrator has the ability to interact with their personal command history as well as view and retrieve the entire organization's command history. The BastionZero SaaS supports log extraction through the API.

Policy

The BastionZero SaaS utilizes the Open Policy Agent (OPA) with an abstraction layer to make it easy for an administrator to create, review, and update policies. All BastionZero APIs are subject to this policy evaluation resulting in an architecture that fundamentally includes a Policy Based Access Control system. This level of granularity provides significant flexibility to provide users differentiating controls as needed.

BastionZero policies include the ability to specify target users and target groups. These are useful for limiting target operations in a Linux shell or Kubernetes API based on Linux users, Kubernetes roles, or groups.

Operations and Management

The web app provides administrator access to the operations and management controls of BastionZero. These core functions regarding how the customer instance operates are secured in a database that is accessed by the BastionZero microservices.

The operations system also implements the target lifecycle process. Targets may exist in one of five states which include:

1. Activation: An agent has requested an activation token.

2. Registered: An agent has presented the activation token to BastionZero.

3. Online: The agent is signaling to BastionZero that it is available to accept connection requests.

4. Offline: BastionZero is no longer detecting any signals from the target.

5. Terminated: The BastionZero target clean up process has detected that an offline target has not checked in within its alloted keepalive time and removed it from the target table.

It's important to note that all targets have UUIDs. Should a target be rebooted, stopped for some amount of time, or stopped nightly, when it signals back to BastionZero its availability, it can return from the offline or termination state to online (security challenges including authentication and authorization withstanding).

Targets

BastionZero targets are servers, VMs, containers, k8s clusters, databases, or web apps within a customer's private or public cloud infrastructure and are accessible via the BastionZero agents. Targets are the resources of BastionZero access policies. Clients make connection requests to targets.

Note that to simplify policy, targets can be grouped into an abstraction called an environment. For example, an administrator can group all production ec2 instances into an ec2-production named environment. Environments can also then be the resource of BastionZero access policies.

BastionZero agents deployed on a target or within the public and private cloud infrastructure are how targets are autodiscovered by BastionZero. To understand the relationship between a target and an agent, we will describe the BastionZero agent next.

Agents

An agent is installed on targets to enable MrZAP and target autodiscovery. These agents are built from the BastionZero open-source agent. Two unique agents are built from the single open-source project: a docker container hosted on Docker Hub and used for k8s targets, and a systemD executable used for servers, VMs, and containers.

The agent running on a target has a number of responsibilities in the BastionZero service. These responsibilities include:

• Implementing the target registration process.

• Performing policy enforcement against the BastionZero security token. Broadly speaking the agent validates that any connection or command request is signed by both BastionZero and a valid SSO user within that organization.

• Autodiscovering themselves to BastionZero with an outbound web socket request. This connection request does not require any inbound ports or public IPs.

• Running the control aspects of BastionZero target to SaaS communication including the keepalive process.

BastionZero agents are lightweight software instances using no CPU and little memory when not being used.