Issue JWS tokens to Builds

Authenticating to external services is a common use case for any CI system. Currently, Buildkite authentication requires either credentials to be stored as “secrets” (whether by SSM, Vault, or injected by the Agent).

This leads to a few common issues:
1. Every service requires its own set of credentials to be provided to the build
2. These credentials are often long-lived
3. These credentials can be easily leaked/extracted from the build.

A simple approach to circumvent some of these issues would be for the Buildkite Server to issue jobs with a signed JWT token, potentially via an environment variable. The Buildkite server would publish the public key used to sign the tokens. Pipelines can then attach the token to outgoing requests, and external services can validate against the public key and authenticate the request. This token could be given a very short expiry (as it only needs to survive the length of the job), and would be completely unique identifier for every job.

Further, external services can optionally authorize resource access conditionally based on claims in the token such as organisation, pipeline, build, etc. They can also log access and actions by specific jobs meaning they provide a strong audit trail.

Such an approach works particularly well when building internal services, and in my opinion, is incredibly useful.

Unfortunately, this is not possible to implement as a plugin, as agents cannot be trusted to sign their own tokens.

Such a system could be built on the JWS specification https://tools.ietf.org/html/rfc7515

I’d love to see something like this. It would pair perfectly with something like Vault in order to isolate a pipeline’s access to secrets or even the auth backends, like we currently do with Kubernetes Service Account tokens.

I’d also be interested in this feature.