Restricting access to agents


Different parts of our organisation need to be restricted to different permissions within our AWS accounts. Currently those permissions are granted to BK agents, via the instance profiles of the EC2 on which they run.

The problem is there appears to be no way to restrict usage of agents within a BK organisation.

To achieve hard separation (e.g. between “admin” and “non-admin” AWS activity) we have resorted to creating two BK organisations each with their own agent pool (the agent EC2s having been configured with suitable IAM profiles).

That does not solve all our problems though - non-admins still need to be able to monitor admin builds, so need to be in the admin org. Even if we set those users to be Read Only for the existing pipelines, merely by being in the admin org it allows them to create new pipelines, which grants them access to the admin agents…something we cannot allow.

The missing BK feature seems to be either:

  • a way to stop users from being able to create new pipelines (not just be Read Only on existing)
  • a way to restrict access to agent queues

The latter is probably the more powerful, but even the first solution would unblock us and might be easier to implement.

Multiple agent tokens per org (with agent queue restrictions)

Thanks for the write up @jukleja-tyro, this is something that we’ve been thinking about a lot and have big plans for.

Our current thinking on approach is that we’re going to introduce the concept of “Agent Clusters”. An Agent Cluster will be able to have Agents with unique queues and tags, and be associated with specific Pipelines and Teams that have access to it.

Organizations will be able to have multiple Agent Clusters and we’re planning to have these form the hard boundaries that it sounds like you are looking for!

We’ve still got a fair bit to work out, but we are planning to also include a move towards public/private keypairs for registering agents vs Agent Registration tokens. This would mean you only ever share your Agent’s Public Keys with Buildkite and we never possess the private key which opens lots of future doors for things like Secrets.

Hope that helps!


Great to hear!

Do you guys publish a roadmap so we can get a rough idea of timescales?

Also as features relating to this get picked up by devs, would you mind reaching out to us so we can confirm your proposed design will meet our need?



We don’t presently publish a roadmap, we might consider it in future! I’d love to give clearer ideas of timeframes, but it depends on a lot of variables and a small team of folks to do the work. It’s on the cards for this year, as part of our #1 priority, Public Builds.

Hopefully sooner rather than later!