Introduction

For IT administrators, developers and technical teams, credentials can become a bottleneck when work moves into terminals, scripts or scheduled jobs. Manual password lookups, copying secrets between tools, and storing credentials in scripts or environment files all add friction and increase the number of places where sensitive information must be handled.

Did you know? Passbolt Go CLI can retrieve credentials, pass secrets directly to commands, and support recurring operational tasks from the command line. 

An open-source tool available for Passbolt’s Community, Pro and Cloud Editions, Go CLI can also create, update, share and delete resources, folders, users and groups without relying on the graphical interface.

This article looks at the most practical Go CLI use cases, followed by the essentials for getting started, helping teams identify where it can add the most value in their existing workflows.

Retrieve a secret without opening the interface

For developers already working in the terminal, Passbolt Go CLI provides direct access to passwords and resources, as well as folders, users and groups, without switching to another interface. This is especially useful for server administration, troubleshooting and other command-line tasks. 

Pass a secret directly to another command

Sometimes a tool needs the credential, and the person running it has to copy or expose the value. Putting tokens or passwords directly into shell commands, environment files or scripts adds unnecessary places where sensitive information can linger. 

Using  passbolt exec lets a command reference the secret stored in Passbolt instead. 

For example, rather than placing the token directly in the environment: 

export ​​GITHUB_TOKEN=my_precious
gh auth login

You can reference the secret securely:

export GITHUB_TOKEN=passbolt://<PASSBOLT_RESOURCE_ID_HERE>
passbolt exec -- gh auth login

So the only thing that can leak is the resource ID,  and not the content itself. 

The passbolt:// reference is resolved to the resource password for the child process only. The secret is not exposed to the parent shell, shell history or standard output, and the Passbolt session is closed before the child command starts.

This makes passbolt exec useful anywhere an existing command-line tool needs a credential but storing another copy of that secret is undesirable.

Automate recurring operational tasks

Passbolt Go CLI can be used in cron jobs and other automated processes like system checks, recurring exports or backups. One example is exporting assigned credentials to a secure off-site location so a recovery copy remains available if the main server is compromised. 

Hence, teams already running scheduled operational tasks can securely integrate Passbolt-managed credentials in their existing process rather than introducing a separate workflow. 

Getting started with Passbolt Go CLI

Install the CLI

Passbolt supported installation options include Homebrew, downloadable binary archives, or Go.

With Go:

go install github.com/passbolt/go-passbolt-cli@latest

On macOS:

brew install passbolt/tap/go-passbolt-cli

Most installation methods provide the passbolt command. A direct Go installation uses go-passbolt-cli instead and does not install tab completion or man pages automatically. Binary archives also require those extras to be installed manually.

Connect a Passbolt account

The CLI needs the server address, private key and private-key passphrase.

The recommended configuration stores the server address and the path to the private-key file, then asks for the passphrase when required:

passbolt configure \

  --serverAddress https://passbolt.example.org \
  
  --userPrivateKeyFile /path/to/privatekey.asc

The private key can be exported from the browser extension profile and should remain readable only by its owner.

The passphrase should not be supplied through --userPassword to avoid storing it in clear text in the configuration file and leave it in shell history. The same applies to supplying an armoured private key directly instead of referencing its file. Private keys without a passphrase are not supported.

The CLI stores its configuration in the standard application configuration location for Linux, macOS or Windows, with restricted directory and file permissions.

Verify the server once

Before using the CLI, verify the Passbolt server:

passbolt verify

The verification information is stored locally and subsequent commands check that the server key has not changed unexpectedly. If the server key is legitimately rotated, verification must be run again.

A setup that relies entirely on environment variables does not retain this verification because there is no configuration file in which to store it.

Start with the commands needed for the job

Commands follow a consistent structure:

passbolt <action> <entity>

The CLI supports actions including create, get, list, update, delete, move, share and export, depending on the entity. Resources, folders, users and groups are supported, while exports can be written in KeePass KDBX format.

To list available resources:

passbolt list resource

To retrieve one, including its password:

passbolt get resource --id <resource-id>

There is no separate search command: search and filter use the same listing functionality with filters. Resources can also be shared with users or groups using Passbolt's existing read-only, update and owner permission levels.

Use structured output in scripts

When a script needs more than the password resolved by passbolt://, resources can be returned as JSON:

passbolt get resource --id <resource-id> --json

The create, get and list commands support JSON output for machine-readable results. Automated processes should check the command's exit status for failures, as errors are not included in that JSON output.

Configure automated environments

For CI runners and similar environments, configuration is recommended to be provided  through the platform's secret store and environment variables rather than running passbolt configure.

The variable names correspond directly to the configuration keys in uppercase like: SERVERADDRESS, USERPRIVATEKEY and USERPASSWORD. There is no PASSBOLT_ prefix, and USERPRIVATEKEY contains the private key itself rather than the path to a key file.

This can be paired with passbolt exec to keep the credentials required by subsequent commands out of runner logs. As noted earlier, an environment-only setup does not retain server verification.

Configure TOTP where MFA is enabled

TOTP is currently the MFA method supported by the Go CLI, with three modes: interactive, non-interactive for automation, or no MFA handling.

The default interactive-totp mode prompts for the current code when required. noninteractive-totp generates the code from a configured TOTP seed for automated workflows, while the third mode none disables MFA handling and will fail if the server requires it.

Because the TOTP seed is sensitive and is stored in clear text when saved through passbolt configure, non-interactive TOTP should only be used where the seed can be provided securely through an appropriate secret store.

Start with the use case that matters

Passbolt Go CLI does not have to begin with a large automation project. For many teams, the value of Passbolt Go CLI is flexibility: adopt it where it makes the most sense today, then extend its use as requirements grow, from individual command-line tasks to more structured automation.

For installation details, configuration options and the full command reference, see the Passbolt Go CLI quickstart guide.