Search…
Dynamic Access Targets
Dynamic access targets (DATs) are machines that are discovered by querying a provisioning server that runs outside of BastionZero. The targets are dynamic because given a specific Dynamic Access configuration, the state, and number of targets online are constantly changing (see more details on the difference between SSM targets and DATs below). The provisioning server has two main responsibilities:
  1. 1.
    Spin up and register a target.
    A target can be a server, container, virtual machine (e.g. EC2 instance), etc. The provisioning server can spin these targets up on-demand or have a pool of targets waiting to be registered; the way these machines are created is up to the provisioning server's implementation. The only requirement is that the server must install bzero-ssm-agent and execute bzero-ssm-agent -register on the spawned targets, so that BastionZero can discover the target. The server should also assign a UUID to the spawned target, so that it can be torn down when it is no longer needed. When BastionZero calls out to the provisioning server, the required parameters needed to execute bzero-ssm-agent -register on the spawned target will be provided.
  2. 2.
    Tear down a target.
    The provisioning server must have the ability to stop and spin down the spawned targets. BastionZero will remember the UUID the server assigned in step (1) and provide the same identifier when asking the server to stop a specific target.
Both of these functionalities should be abstracted behind two distinct HTTP POST endpoints, which the provisioning server must implement. Details on the full API specification, including a Python Flask reference implementation, is available here.
The provisioning server's architecture, due to being designed as POST webhooks, allows for dynamic targets without requiring BastionZero to have privileged access or special roles in an organization's cloud/network.

Why Use DATs

DATs encourage users to use ephemeral targets to access certain resources in an organization's network. Once the resources have been polluted by a user's access, the target may be torn down. For instance, one may require that any hands-on-keyboard database migration be performed from a fresh target container that is killed once the migration is complete.
The differences between SSM targets and DATs explained here demonstrates how DATs fit the ephemeral model described in the example above.

Configuring DAT

Because DATs are dynamically created by querying a provisioning server, an organization administrator must first add a Dynamic Access configuration before other users in the organization can ask to connect to a DAT. Every DAT has a backing Dynamic Access configuration which determines how the target is spun up (provisioned) and torn down (destroyed).
An organization administrator has the ability to add a Dynamic Access configuration in the Create dropdown menu found in the top-right corner of the BastionZero web app.
Image of a DAT configuration
Below is an explanation of each configuration option:
  • Name: A unique name that is used to refer to this Dynamic Access configuration. This is the name that appears in the Targets screen and Connect screen on the BastionZero web app. It is also the name that is used when a user wishes to connect to a DAT via the zli.
  • Environment: The environment that contains all DATs registered by the backing provisioning server. The environment determines the policies to apply to the spawned targets and therefore which users can access them.
  • Start webhook: The URL of the provisioning server's POST start endpoint. This endpoint is queried by BastionZero when it requests the server to spin up and register a target. Example: https://dynamic-access.example.com/start.
  • Stop webhook: The URL of the provisioning server's POST stop endpoint. This endpoint is queried by BastionZero when it requests the server to tear down a target. Example: https://dynamic-access.example.com/stop.
  • Health webhook: The URL of the provisioning server's GET health endpoint. This endpoint is queried by BastionZero periodically to check that the provisioning server is still online and accessible. Example: https://dynamic-access.example.com/health.
  • Shared secret (base64): A shared secret between the provisioning server and BastionZero that is used to ensure only BastionZero is authorized to query the provisioning server. See more details in the reference specification's README found here.

Connecting To a DAT

Once the Dynamic Access configuration has been added, authorized users, as defined by the organization's policies, can connect to a DAT provisioned by the server specified in the configuration.

Connecting Via the Web App

To connect to a dynamic access target via the BastionZero web app, a user clicks on the Connect button found on the Spaces screen and finds the name of the Dynamic Access configuration in the list of accessible targets. This UX experience should be familiar as it is exactly the same flow as when connecting to SSM targets.
Picture of connecting to DAT via the web app

Connecting Via the zli

To connect to a dynamic access target via the zli, a user executes a command similar to the following one:
1
zli connect [email protected] --dynamic
Copied!
db-dat is the name of the Dynamic Access configuration, and ssm-user is a default user that exists on all DATs. The user can specify a username not equal to ssm-user as long as the specified username actually exists on the provisioned machine, and there exists a policy that allows access to such Target User.

DATs Vs. SSM Targets

Once a DAT is fully provisioned and registered, a DAT does not appear differently from the user's perspective. It is listed as an SSM target in the list of the organization's targets (Targets screen), and the user connects to it through the same flow like SSM targets as described above. In fact, the provisioned target is running the same bzero-ssm-agent that is installed when registering a target via the Autodiscovery script or zli quickstart.
DATs differ from SSM targets in three ways:
  1. 1.
    How they are discovered and initially connected to by BastionZero.
  2. 2.
    The lifetime of DATs.
  3. 3.
    The policies involving DATs.

Discovery and Initial Connection

Unlike SSM targets, which are discovered by BastionZero once an administrator runs the Autodiscovery script, DATs are discovered on a per-user basis when the user asks to connect to a DAT. A single user cannot have more than one DAT target created by the same Dynamic Access configuration. The name of discovered DATs hint at this exact property: DAT-<name-of-dynamic-access-config>-<User's full name>.
When processing the connect request, BastionZero sends a POST request to the start webhook as defined in the Dynamic Access configuration. This request notifies the provisioning server that a fresh target should be created.
Because it can take the provisioning server some time to spin up a target, the terminal shell that appears after making the initial connection will be in the loading state. The shell cannot receive any input until the target is fully provisioned - that is until the target is fully registered, online, and reachable by BastionZero.
This initial connection experience is different than when connecting to an SSM target because of the nature of a DAT. A DAT's existence is known at the time of an initial, user-initiated connection. An SSM target, on the other hand, is known at the time of registration, which happens during the autodiscovery process. Due to this difference, an initial connection to a DAT will often take longer than when connecting to an SSM target whose existence is already known ahead of time.
Notice, however, that once the initial connection is made and not closed, future DAT connections made by the same user who initially connected, will finish connecting much faster than before. This is because all future connections to the same Dynamic Access configuration will connect to the already provisioned and running DAT created for the specific user.

Lifetime of DATs

DATs are meant to be used as ephemeral targets; therefore, the lifetime of a DAT is fairly short compared to an SSM target. A DAT target is automatically deleted once there are no more connections to it. When the last connection is closed, BastionZero sends a POST request to the stop webhook as defined in the Dynamic Access configuration. This request notifies the provisioning server that the backing machine should be destroyed and is no longer needed.
An SSM target, on the other hand, will not be deleted unless the user explicitly deletes it from the Targets screen or if the environment's offline target removal policy timeout is reached.

Policies of DATs

Similar to other kinds of targets, DATs are protected by the organization's policies. The two types of Target Access policies, environment-specific and target-specific, are applicable to DATs. However, there is a notable difference in a target-specific policy compared to SSM targets. A target-specific policy cannot refer to one of the spawned DATs; it can only refer to a specific Dynamic Access configuration.
The effect of this difference is as follows:
  • If the organization only has a target-specific policy for some Dynamic Access configuration, authorized users can only access the DATs created for them (i.e., the ones with the name DAT-<name-of-dynamic-access-config>-<User's full name>).
  • If an administrator wants to allow users to access DATs that were not created for them, then an environment-specific policy that refers to the Dynamic Access configuration's environment must be used.
Last modified 20d ago