Administrators' guide to managing authorization in BastionZero
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 straightforward policy model involving subjects, actions, and resources. Subjects are entitled to perform an action based on the successful evaluation on a policy. All policies are therefore permissive in nature.
The Kubernetes policy provides end users the ability to perform
kubectlactions, 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
k8srole binding was made. BastionZero is very flexible in this regard, and the
k8scommand logs will again disambiguate which SSO user executed which
kubectlcommand within a particular user or group to role binding.
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
postgresas 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.
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. This can be configured via the policy action field.
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.
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-useras the allowed target user. Through the BastionZero command logs, the administrator can then identify which SSO user entered what command as the
ec2-useron 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 to use for that connection.
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.
View of an organization's keys in the BastionZero web app
BastionZero supports passing your API key using the
X-API-KEYheader for any application, such as Postman, curl, or your own business logic.
All API requests are made over HTTPS.
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.
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