bzero
, is compatible with x86
and amd64
platforms. It is available through apt
and yum
package managers, a Bash script, a guided zli
Quickstart, Ansible playbook, and via helm
and yaml
for Kubernetes.yum-config-manager
to add the BastionZero repo.bzero
.apt
cache.bzero
.bzero
agent using Bash through the zli
or the web app.zli
-n
and -e
flags respectively.-o
flag to save the Bash script to a file directly.bzero
agent and secures your target host(s) in less than 10 minutes.bzero
agent with Helm requires a registration secret.apiKey
clusterName
image.agentImageTag
latest
will be used as the default.namespace
default
namespace, which is not recommended.create-namespace
--create-namespace
. If adding to an existing namespace, this argument must be omitted.agentResources.limits.cpu
agentResources.limits.memory
agentResources.requests.cpu
agentResources.requests.memory
quickstartResources.limits.cpu
quickstartResources.limits.memory
quickstartResources.requests.cpu
quickstartResources.requests.memory
--set "users={SOME_ID_USERS}"
[email protected]
) to add users automatically to the auto-generated policy. This will allow you and others permission to connect to your cluster right away.--set "targetUsers={SOME_KUBE_USERS}"
ClusterRoleBinding
or RoleBinding
that has a user as a subject. The name of this user is what we'll impersonate.--set "targetGroups={SOME_KUBE_GROUPS}"
--namespace
flag determines which namespace to install the BastionZero agent in. If the namespace already exists, omit the --create-namespace
flag.--namespace
flag, then the agent will be installed in the default
namespace, which is not recommended.latest
for the agent. We strongly recommend that you override that using the flagbzero
agent with Pulumi via Helm requires a registration secret.bzero
agent with Helm requires a registration secret.clusterName
from the previous installation.clusterName
from the previous installation.clusterName
is the name of your cluster. This command will generate a Kubernetes YAML with a Service Account, RBAC permissions/bindings, secret, and deployment.someFile
is the name of your YAML file.bzero
.-registrationKey
flag is required.-registrationKey
-environmentName
environmentId
. If neither environmentName
nor environmentId
is provided, the target will be placed in the default
environment and can be assigned a new environment via cloud.bastionzero.com.-environmentId
environmentName
. If neither environmentName
nor environmentId
is provided, the target will be placed in the default
environment and can be assigned a new environment via bastionzero.com.-targetName
-org
-orgProvider
-org
nor the -orgProvider
are set, the information defaults to values provided by BastionZero during the registration process.-y
-y
flag to force re-registration and create a new target. The old target will be deactivated.bzero
, will initiate an outbound connection to the BastionZero SaaS from any private or public cloud. In some cases, like an application-based firewall, the administrator may need to allow the BastionZero DNS entry or IP, but that is organization-specific. The only requirement for autodiscovery is that the agent can get out to the Internet.bzero
agents support error handling and recovery as part of the registration and activation process.bzero
agent can be installed on your remote server in a variety of ways: package managers, Bash script, Ansible playbook, or zli
Quickstart.bzero
agent through the zli
, during instance launch (i.e., by using the user data with AWS EC2), a Terraform deployment, or other deployment system.bzero
agent via an Ansible playbook. The Ansible playbook implements the autodiscovery process. Using your organization's default registration secret, or an administrator's registration secret, the playbook will request an activation token from BastionZero and then phone home to the service with an outbound connection. Registration in this case does not require any additional action from you. See here to learn more about generating a registration API key.zli
for end users to make connections. When connecting to a database target, traffic destined for the database will use local port forwarding through the zli
and the proxy target to make a secure MrZAP connection to the database. Upon requesting a connection, the user is returned a local port number, which is used in the database client configuration. The database username, password, and role continue to be managed independent of BastionZero.bzero
agent. The agent can be installed on your server in a variety of ways: package managers, Bash script, Ansible playbook, or zli
Quickstart.zli
will listen on. This should not need modification.zli
will use to intercept traffic. If you leave it blank, an open port on the client machine will be selected for the user.proxy
and update and save the fields per the descriptions below.clusterRoles
and clusterRoleBindings
.{clusterName}
."{clusterName}-policy"
and "{clusterName}-env"
respectively.cluster-admin
is an approved Kubernetes user that can access the cluster. Notably, this does not create a Kube policy on the cluster itself for access.zli
for end users to make connections. When connecting to a webserver target, the user's default browser will open a new tab with the connection to the web service. This new connection will utilize a local port via a TCP socket to the BastionZero SaaS. This connection is made through the MrZAP protocol. As a result, BastionZero can authenticate and authorize the access, but it cannot alter any commands sent across.bzero
agent. The agent can be installed on your server in a variety of ways: package managers, Bash script, Ansible playbook, or zli
Quickstart.zli
will listen on. This should not need modification.zli
will use to intercept traffic. If you leave it blank, an open port on the client machine will be selected for the user.proxy
and update and save the fields per the descriptions below.bzero
agent and register itself with BastionZero on each spawned 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 -registrationKey
on the spawned target will be provided.POST
webhooks, allows for dynamic targets without requiring BastionZero to have privileged access or special roles in an organization's cloud/network.zli
.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
.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
.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
.zli
zli
, a user executes a command similar to the following one: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.bzero
agent that is installed when registering a target via any autodisdovery method.bzero
agent, 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>
.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.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.DAT-<name-of-dynamic-access-config>-<User's full name>
).zli
. The zli
then creates an SSH tunnel directly to the target. The SSH tunnel is passed over a websocket from the zli
to BastionZero. From there, it is passed over a different websocket from BastionZero to the target.zli generate ssh-proxy
and configure your .ssh/config
file with two lines:bzero
:$ ssh [email protected]
$ ssh -L 6100:127.0.0.1:5432 [email protected]
$ ssh -L 8080:10.0.0.1:80 [email protected]