Authorization

Product Pricing Main Site Sign In / Try Now
Search…
Authorization
Administrators' guide to managing authorization in BastionZero
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.
​Policies on the web app​
Policy Types
Target Access
The target access policy provides users and groups 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.
Target access policy in the 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 SSO user entered what command as the ec2-user on a particular target.
When an SSO 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 SSO user must select which target user they will use for that connection as per below.
How an end user would need to select which user they'd like to connect as to a BastionZero target
Proxy
The proxy policy in BastionZero provides users and groups the ability to access databases or webservers from a specific target or environment. 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.
Proxy policy in the web app
Similarly to the target access policy, proxy policies have the ability for the administrator to specify one or more target users available to the subjects of the policy. For example, if writing a proxy policy to a Postgres database,the administrator can specify the default postgres as the allowed target user.
When an SSO 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 SSO user must select which target user they will use for that connection.
Session Recording
The session recording policy provides administrators the ability to record a user and group shell sessions. By default, BastionZero records stdout. However, the administrator has the option to also record stdin.
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.
​All available session recordings in your organization​
Kubernetes Tunnel
The Kubernetes tunnel policy provides end users the ability to perform kubectl actions, including shell exec, against the cluster. An SSO 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 SSO user executed which kubectl command within a particular user or group to role binding.
Kubernetes cluster access policy
API Keys
BastionZero uses two forms of API keys within the product:
1.API access keys to authenticate all API requests.
2.Registration API keys to register targets with BastionZero.
All API keys are managed by the administrator. The web app and the BastionZero API supports full API lifecycle key management.
Even with a valid API key, all API requests are subject to a policy check before they are permitted to execute. All active API and Registration API keys are shown in the API dashboard.
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 strongly recommend storing your API secrets in a vault or other secure storage. Avoid storing keys in files, code, or anywhere public.
BastionZero supports passing your API key using the X-API-KEY header for any application, such as Postman, curl, or your own business logic.
All API requests are made over HTTPS.
Registration API Keys
NOTE: Registration API keys are reusable. There is no need to generate a new key for each target registration.
Registration keys can only be used to register targets. Any attempt to use a registration key for non-registration APIs will fail because the policy check will return Deny. Registration keys can be associated to an application, an end user, or an administrator in multiple ways within BastionZero.
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 administrator's registration key is used when requesting autodiscovery scripts.
Creating an API Key
Navigate to https://cloud.bastionzero.com.
The log in screen for cloud.bastionzero.com
Log in using the same credentials you use for your identity provider. Once complete, you’ll see the main page show below.
cloud.bastionzero.com main page
Select "Create" in the upper righthand corner and choose "API Key." For Registration keys, you MUST select the Registration key box below the name field. Clicking "Generate API Key" will then display the new API key ID and secret.
For demonstration purposes: a newly generated Registration API key
Once the API key pair is created, the key ID and secret are displayed. This is the only time the secret is available. Once saved, the secret cannot be retrieved by an admin. We strongly recommend storing your API secrets in a vault or other secure storage. Avoid storing keys in files, code, or anywhere public.