Learn · Secrets and agent security

Constraining what agents will run

A Buildkite plugin is code from somewhere else that runs on your agent, inside your build, with whatever access that agent has. That is useful and it is also the shape of a supply-chain problem.

allowed-plugins

The agent’s allowed-plugins setting takes a comma-separated list of regular expressions. Before running a job, the agent checks each of the job’s plugins against the patterns. If any plugin does not match at least one pattern, the agent refuses to run the job.

It fails closed. An unapproved plugin does not get skipped with a warning — the job does not run.

Shorthand references are expanded before the check, so docker-compose#v5.0.0 is tested as github.com/buildkite-plugins/docker-compose-buildkite-plugin#v5.0.0. Write your patterns against the expanded form.

Because they are regular expressions, you can pin versions as well as sources — which is the point. Allowing docker-compose at any version means allowing whatever that plugin becomes next week.

no-plugins

For agents that should never load third-party code at all — the queue that holds your production deployment credentials, say — no-plugins disables plugins entirely.

This pairs with the queue boundary from the previous unit. A sensible topology often has permissive plugin policy on the queue running tests and none at all on the queue running deploys.

Pipeline signing

Restricting plugins constrains what a pipeline may load. Pipeline signing and verification addresses a different question: whether the steps an agent is about to run are the steps that were actually authorised, or something modified in transit.

The two are complementary. One controls the ingredients, the other controls the recipe.