Access management

Manage users, groups, roles, and permissions from the command line.

Bronto access control has users, groups of users, and roles that bundle permissions. Access Control and User Management on docs.bronto.io explain the model, and the API reference documents users, groups, roles, and permissions. The commands below follow the shared resource pattern and need an API key with the Admin role.

​

Users

$ bronto users list
EMAIL              FIRST_NAME  LAST_NAME  STATUS  LAST_LOGIN  ID
[e-mail]    Ada         Lovelace   ACTIVE  3h ago      e5d7f3c6-8fa2-43c5-b061-2c9f7e4d5a05
[e-mail]  Grace       Hopper     ACTIVE  1d ago      f6e8a4d7-9ab3-44d6-c172-3dab8f5e6b06
$ bronto users get [e-mail]
{
  "email": "[e-mail]",
  "first_name": "Ada",
  "id": "e5d7f3c6-8fa2-43c5-b061-2c9f7e4d5a05",
  "invited_at": 1776762000000,
  "last_logins": {
...
  },
  "last_name": "Lovelace",
  "roles": [
    "Admin"
  ],
  "status": "ACTIVE"
}

get prints the full record as JSON, even at a terminal.

Users resolve by email anywhere an id is accepted. The user commands beyond CRUD:

$ bronto users groups [e-mail]
NAME    DESCRIPTION                     GROUP_ID
oncall  Paged by the checkout monitors  0a7b9c3d-1e2f-4a5b-8c6d-7e8f9a0b1c07

bronto users resend-invite [e-mail]
bronto users deactivate [e-mail]
bronto users reactivate [e-mail]

bronto users groups lists the groups a user belongs to. bronto users deactivate and bronto users reactivate switch a user off and back on. The STATUS column of bronto users list confirms the change. bronto users resend-invite sends a new invitation to a user who hasn’t accepted yet.

​

Groups

$ bronto groups members oncall
GROUP_ID                              MEMBER_ID                             MEMBER_TYPE  MODIFIED_AT
0a7b9c3d-1e2f-4a5b-8c6d-7e8f9a0b1c07  e5d7f3c6-8fa2-43c5-b061-2c9f7e4d5a05  USER         2026-05-04
0a7b9c3d-1e2f-4a5b-8c6d-7e8f9a0b1c07  f6e8a4d7-9ab3-44d6-c172-3dab8f5e6b06  USER         2026-06-02
$ bronto groups list
NAME    DESCRIPTION                     CREATED_AT  GROUP_ID
oncall  Paged by the checkout monitors  2026-05-04  0a7b9c3d-1e2f-4a5b-8c6d-7e8f9a0b1c07

groups members lists members by id. Here they are Ada and Grace, as the ids in bronto users list show.

Add or remove members with bronto groups add-members and bronto groups remove-members. Both take users by id or email with --users, and other groups by id or name with --groups. Each flag takes a comma-separated list or can be repeated.

bronto groups create -f name=sre -f description="Site reliability"
bronto groups add-members oncall --users [e-mail],[e-mail]
bronto groups add-members oncall --groups sre
bronto groups remove-members oncall --users [e-mail]

groups update replaces the group’s name and description: the API clears whichever one you leave out. Pass both, repeating the current value of the one you keep. The CLI refuses an update without both:

bronto groups update oncall -f name=oncall -f description="Paged by every prod monitor"

--dry-run resolves the group and the users and prints the request it would send, without making the change:

$ bronto groups add-members oncall --users [e-mail] --dry-run
{
  "body": {
    "members": [
      {
        "member_id": "f6e8a4d7-9ab3-44d6-c172-3dab8f5e6b06",
        "member_type": "USER"
      }
    ]
  },
  "dry_run": true,
  "method": "POST",
  "path": "/groups/0a7b9c3d-1e2f-4a5b-8c6d-7e8f9a0b1c07/members"
}

​

Roles and permissions

bronto permissions list prints the permission names a role can grant:

$ bronto permissions list
GROUP     NAME            TYPE   DISPLAY_NAME
logs      logs_read       READ   Read logs
logs      logs_write      WRITE  Write logs
monitors  monitors_read   READ   Read monitors
monitors  monitors_write  WRITE  Write monitors
$ bronto roles list
DISPLAY_NAME  ROLE_TYPE  IS_SYSTEM_ROLE  DESCRIPTION                      ROLE_ID
Admin         USER       true            Full access to the organization  Admin
Read only     USER       true            Search and view, no changes      ReadOnly

System roles have readable ids such as Admin and ReadOnly, and a role also resolves by its display_name.

roles update replaces the whole role, so omitted fields are cleared. Pass display_name and the exact set of permissions the role should have. The CLI refuses an update body without them.

bronto roles create -f display_name=Viewer -f 'permissions=["logs_read","dashboards_read"]'
bronto roles update Viewer -f display_name=Viewer -f 'permissions=["logs_read"]'

Don’t copy permissions from roles get output into an update. Reads return the full permission catalog, including permissions the role doesn’t grant.

Values passed with -f are parsed as JSON, so the permissions value above is sent as an array.

​

API keys

API keys have bronto api-keys list, create, update, and delete. create prints the full key, including in the JSON it prints when piped, and is the only time you can see the secret part: store it right away. list shows only the key’s id part, masked unless you pass --reveal. See API Keys on docs.bronto.io for the roles a key can have.