Improving authentication with the CLI

We've been busy making changes to the way the Buildkite CLI can authenticate against organizations. We've implemented some features, as well as improvements to security so folks can feel safer in giving the CLI assess to their Buildkite organization.

OAuth availability

The CLI can now be authenticated via OAuth, with permissions scoped within the user's own accepted access. The permissions can also be customized to meet your needs for CLI use.

A single auth family

We've introduced an auth command, with various subcommands, to ensure all things authentication can be found in a logical spot. whoami and use can still be used, for now, performing the same actions as their new subcommands, bk auth status and bk auth switch, respectively.

We've also implemented bk auth login, replacing configure add, and bk auth logout, a new command which will clear keychain credentials for the current authenticated organization, or all keychain configurations with the --all flag.

No more text-based tokens

The CLI, until now, has been writing API tokens to a config file, typically at ~/.config/bk.yaml, which is convenient but a pattern we've wanted to move away from. As of v3.32.0, we'll no longer write to this file, only read from it. API tokens will be encrypted and stored in the OS keychain exclusively.

The CLI will fall back to reading bk.yaml files, so if those are in use, or you wish to continue using them, you can, you'll just see a warning in the terminal when you do. If you do wish to store API tokens in your bk.yaml file, you can manually adjust the file;

organizations:
  my-cool-org:
    api_token: bkua_hunter28265989387498729792378

A lot to take in? Read the Buildkite CLI documentation