Admin View
An administrator of BastionZero has full application, visibility, and control of the service. These areas can be classified as:
In addition, an administrator is also an end user. As such, an administrator may have access to one or more of the access technologies supported by BastionZero's web app as discussed in the next section.
Let's focus on the administrative controls first.

User Management

BastionZero uses your IdP as the root-of-trust to authenticate users in your organization. The first time a user authenticates, an associated username is created within BastionZero with a BastionZero UUID for that user. If no policies exist, that user has access to the web and zli clients but will be unable to use any of the features associated with BastionZero.
An administrator can choose to delete a user from BastionZero. In doing so, the administrator is removing the association between the IdP user and the BastionZero UUID. That has the net effect of removing that IdP user from all policies and immediately closing any open connections. However, their events, like command and connection logs, will remain within BastionZero and be accessible to the administrators. If the same IdP user is subsequently added back to BastionZero, that will create a new BastionZero-associated UUID and thus, new policies would need to be created for that same IdP user.
In addition, an administrator can take actions on behalf of the user, such as requiring a reset of a user's BastionZero MFA or optionally (and not recommended) disabling that user's MFA all together. An administrator may decide to close all existing user's connections. All administrative user actions can be found in our web app's Manage Users Table page.
As stated previously, BastionZero respects user authentication from your IdP. As a result, BastionZero follows the security posture maintained by your IdP. When a user is deactivated from your IdP, they are deactivated from BastionZero. This means they will fail the organization check by the MrZAP protocol, and any subsequent action attempted will expire with their security token.

IdP Groups

Optionally and if so configured by an administrator, BastionZero can read and use IdP groups when authoring policy. This read-only permission is only used to look up group names and users in that group when a policy is authored or otherwise modified. BastionZero does not take a snapshot of your IdP or maintain its own copy of your IdP user and group settings. The policy authoring is the only action that results in a group and username lookup.
Groups are especially useful in authorizing policies. When a new hire is onboarded, adding them to an IdP group will add them to all similiarly associated BastionZero policies that contain that group. That update process occurs under the following circumstances:
  • An immediate webhook notification for any organization using Okta.
  • Within 1 hour for any organization using Azure (Microsoft) or Google.
  • An immediate update when the policy is saved by a BastionZero administrator.

Connection Management

BastionZero manages the lifecycle of both connections and targets. There are features in place for different connection types, such as shells, SSH tunnels, and k8s clusters, as well as targets, which may be long-lived, shutdown and restarted, or ephmeral.

Client Connections

BastionZero clients and targets make websocket connections to the service. Across the websockets, users make shell, SSH tunnel, HTTP, or native TCP connections based on the access technology. All of these connections transparently use MrZAP technology.
Shell connections can be made using both the web app and the zli. The shell terminal runs in the BastionZero SaaS. This provides users the ability to run a long-lived shell connection, like during a database migration, without concern for keeping the end user's device active. Idle shell connections are maintained by BastionZero for up seven days or until the user or administrator closes them. Future versions of BastionZero will provide the administrator the ability to control this time frame.
SSH tunnels or shell sessions run over an SSH tunnel are unique in that the data sent through BastionZero is fully encrypted to BastionZero. Thus command logs and session recordings are not available for any connections that run over this type of connection. SSH tunnels are only supported by the zli MrZAP protocol. When a user logs out of BastionZero, all SSH tunnels are terminated. In addition, if a user's authentication token is invalidated by the IdP for any reason (like a 1 hour ID_token expiration), SSH tunnels will also be invalidated.
SSH tunneling is a very powerful feature. It can be used to forward any protocol to any destination behind a perimeter like a database, web server, or any legacy application, or target not natively supported by BastionZero. By default, all BastionZero target access policies disable SSH tunnels.
Coming in Early Q1 2022
Native TCP connections are used for database and web server targets (in lieu of SSH tunnels) where an administrator wants simplified deployment as well as connection and query logs for these types of targets.
This feature is offered through the zli, and like SSH Tunnels, the native TCP connection is terminated by a user logout or IdP identity token expiration.
Contact [email protected] for access to this preview feature!

Target Connections

After successfully completing the registration process, all targets make a websocket connection to BastionZero. This outbound connection to the BastionZero SaaS is the only connection that is made from the target to BastionZero. All other connections are initated by a client request and go through this websocket.
The target will maintain a keepalive across the websocket. This keepalive is used to determine whether the target is online or offline by the BastionZero SaaS. If a target goes offline no new connection attempts are made and all existing connections are closed.
A targets online / offline status also plays a role in its target table appearance. Recall that groups of targets may be place in an environment. Environments have a target lifecycle management feature called the Offline Target Removal Policy. This is an expiration timer that can be set from 1 hour to 90 days. Any target that is offline for that time period will be removed from the target table. An administrator may set this time by visiting the (Manage Environments Table page.

Policy Management

The BastionZero SaaS implements policy-based access controls using the Open Policy Agent. On top of OPA, BastionZero provides its own abstraction layer for all policy types provided to the administrator. These policies are designed to be simple to implement and manage over time.
BastionZero employs a very simple policy model involving subjects, actions, and resources. Subjects are entitled to perform an action based on the successful evaulation on a policy. All policies are therefore permissive in nature.

Target Access

The target access policy provides users, groups, and API keys (the subjects), the ability to shell, tunnel, or copy, from a specific target or an environment (a group of targets). Each of these parameters can be enabled independent of or with each other. The policy can be specified through the web app or directly using the BastionZero API.
Image of an example of a target access policy in BastionZero's web app
In addition, the target access policy has the ability for the administrator to specify one or more Linux users available to the subjects of the policy. For example, if writing a target access policy to an AWS EC2 instance, the administrator can specify the default ec2-user as the allowed target user. Through the BastionZero command logs, the administrator can then identify which IdP user entered what command as the ec2-user on a particular target.
When an IdP user appears in more than one policy for the same target, as in the case where that user may have access to both a read-only and privileged target user, the IdP user must select which target user they will use for that connection as per below.
Example of how an end user would need to select which user they'd like to connect as to a BastionZero target

Session Recording

The session recording policy provides administrators the ability to record a user and group shell sessions, whether they are initiated from the web app or zli. By default, BastionZero records stdout. However, the administrator has the option to also record stdin.
Example of a BastionZero session recording policy in the web app
BastionZero shell recordings are live; at any time, an administrator may view, download, or even delete, a recording in progress. BastionZero will keep recording the user's shell session until the user is removed from the policy or the policy is removed from the system.
BastionZero uses ascinema as its session recorder. These recordings may be downloaded, searched, and are displayed in fast intervals as opposed to the experienced user time.

Kubernetes Tunnel

The Kubernetes tunnel policy provides end users the ability to perform kubectl actions, including shell exec, against the cluster. An IdP user may assume a particular cluster role, based on policy. This role can be defined as a particular target user or target group depending on whether a user or group was specified when the k8s role binding was made. BastionZero is very flexible in this regard, and the k8s command logs will again disambiguate which IdP user executed which kubectl command within a particular user or group to role binding.
Example of a Kubernetes cluster access policy


BastionZero generates many types of events. Similar events are grouped together to create log views. BastionZero currently maintains five different types of event logs available to administrators through the web app and the API. All event types that comprise logs can be retrieved from the BastionZero API as a group or filtered based on criteria, like an IdP user, target user, or target name, just to mention a few.
All logs are updated in real time as they come into BastionZero and are stored with a UTC timestamp. Your web browser will convert the UTC timestamp to the browser local time, and thus all events from anywhere in the world are seen in order when viewing from any time zone.

Command Logs

Command logs are events associated with shells. They are the command line event typed at the shell by the user. BastionZero records which IdP user ran what command on which target as what target user.

Kubernetes Logs

Kubernetes logs are events associated with executing k8s API either using kubectl or the zli clients. Regardless of whether an end user uses kubectl or the zli, BastionZero records the timestamp, IdP user, target cluster, target user or group, and API associated with the command. When the zli is used, BastionZero also records the command text associated with the command. Further, when the zli is used to exec into a container, BastionZero will record that shell command text as well.

Connection Logs

Connection logs are events associated with clients interacting with targets. Client connection event types can be open, closed, connected, or disconnected. All connection events include the timestamp, the IdP user, a unique connection ID, the connection event type, the space from which it orginated, the target user, and finally the target name.
Closed connection events can originate from the end user, the administrator, or BastionZero. The logs will reflect who closed connections by username or by action. For example, if a target is deleted by an administrator, all current connections are closed. The connection log will reflect that the connection was closed as a result of [email protected] deleted target. Closed connection events are also the result of closing or terminating SSH tunnels or native TCP connections.
Disconnected connections result when the web app is closed by the user logging out or when exiting a zli-based shell connection. In these cases, the shell is still running on the BastionZero SaaS, but the client is no longer active. By re-authenticating to the web app or by attaching in the zli, the connection is restored and a connected event is generated.

User Events

User events are a form of audit log within BastionZero. As previously stated, every action in BastionZero is an API. Every API event, whether it be from an administrator updating or listing a policy, an end user making a connection, or an application using an API key, is recorded in the form of a user event.

API Keys

BastionZero supports two types of API keys: registration and app (API access) keys. All API keys are managed by the administrator. The web app as well as the API supports full API lifecycle key management.
View of an organization's keys in the BastionZero web app
Once an API key pair is created, the key ID and secret are displayed to the administrator. This is the only time the secret is available. Once saved the secret cannot be retrieved by an admin. We recommend storing your API secrets in a vault or other secure storage.
Registration keys can only be used to register targets. Registration keys can be associated to an application, an end user, or an administrator in multiple ways within the service.
The services will default to enforcing and using Global Registration Key Settings. In this case:
  • All registration keys are created and assigned by the administrator.
  • The default registration key is used when autodiscovery scripts are requested from BastionZero by an administrator.
If the Global Registrator Key Settings are disabled:
  • All administrators are provided their own unique registration key pair.
  • Administrators may create and assign additional registration keys.
  • The administrators registration key is used when requesting autodiscovery scripts.
All other API keys can be used to access BastionZero APIs as further defined in our product documentation.

App Integrations

BastionZero supports native app integrations to simplify administrative workflow management. The focus on BastionZero's integrations has been to simplify user management by supporting the organization's lifecycle management of IdP users and groups.
Please contact [email protected] for the latest integration roadmap or to make product suggestions. We'd love to hear from you.
Last modified 19d ago