Britive Script Helper (bsh)
Britive Script Helper, or bsh, is an optional command-line helper for scripts. It creates accounts, grants access, or rotates credentials during . At , it removes the grant or invalidates the issued credential, according to the selected method.
You can write your own checkout and checkin scripts, adapt the provided custom scripts in the integration guides, or call bsh for supported operations. These pages describe the bsh approach using version 0.2.0.
A permission script that calls bsh specifies the protocol and the operation to perform. For example, this checkout script uses bsh to create a Linux account and install a generated SSH key:
#!/bin/sh
exec bsh checkout ssh --method ephemeral-keyThe matching checkin script removes the key:
#!/bin/sh
exec bsh checkin ssh --method ephemeral-keyThe permission supplies the user identity, target, credentials, and other settings through its variable mappings. bsh reads those values under names such as BSH_USER_EMAIL and BSH_TARGET_HOST.
How bsh fits into a permission
The Britive platform sends a checkout or checkin request to the broker. The broker runs the permission’s configured script and returns its result to the platform. For permissions that use bsh, the script calls the helper to perform the selected operation.
Three settings determine what bsh does:
| Setting | Purpose | Example |
|---|---|---|
| Protocol | The service the user accesses | ssh, postgres, or rdp |
| Method | The access operation | ephemeral-key, temp-user, or role-grant |
| Transport | How the broker reaches the target to perform that operation | ssh, database, or winrm |
In bsh, the protocol and transport can differ. For example, bsh uses WinRM to create a Windows account for an RDP permission. It can use SSH to rotate a VNC server password.
The transport account is the administrative identity bsh uses to manage access. The target account is the identity the user receives or already owns. They have separate settings and credentials.
Standard and Bridge modes
In standard mode, checkout returns credentials or grant details to the platform. JSON is the default output format. Methods that issue a single credential can also return that credential as raw text.
In Bridge mode, bsh provisions access and registers a checkout with Britive Bridge. The response contains the transaction ID and connection details. Target credentials are sent to Bridge. Telnet also returns the target password because the user enters it at the target’s login prompt.
Bridge mode requires Britive Bridge 3.0.0 or later and a broker with access to Bridge’s broker API. The platform transaction ID must reach both checkout and checkin.
Supported access operations
bsh supports Unix accounts and SSH keys, Windows accounts, Active Directory and LDAP access, SQL and NoSQL database accounts, Kubernetes ServiceAccount tokens, and Bridge sessions.
Available methods depend on the protocol. For example, ssh ephemeral-key creates an account if needed, while ssh existing-user-key requires an existing account. bsh does not support RESTCONF or vendor-specific network-device provisioning.
The protocol and method reference lists the supported combinations and checkin behavior.