Local agents deprecated in 2021; no longer available in Bamboo 9.6+

[#1]

Local agents, that run in the same JVM as the Bamboo server, were part of the Bamboo Server offering from the start.

However, local agents caused several problems for Bamboo Server. For example, local agents run in the server's process and result in security and performance issues, such as the execution of arbitrary code with the privileges of the Bamboo server process or denial of service by using too many resources. Further, local agents were not designed with a multi-node Bamboo Data Center setup in mind, in which agents are no longer local (e.g. you can’t enforce a plan to run from a local agent on node A or node B).

Because of these issues, and to ensure that Bamboo Data Center could meet enterprise-grade requirements (such as security, performance, and multi-node setup), local agents were deprecated in Bamboo Server and Data Center 8.0. In all versions of Bamboo 9.6 and above, they will no longer function.

If your instance relies heavily on local agents, we recommend remaining on Bamboo version 9.5 until you’re ready to consider Remote, Ephemeral, and Elastic agents as a viable alternative.

Learn more about different agent types:

• Remote agents | Bamboo Data Center 9.4 | Atlassian Documentation
• Managing your elastic agents | Bamboo Data Center 9.4 | Atlassian Documentation
• Ephemeral agents | Bamboo Data Center 9.4 | Atlassian Documentation

Learn more about Bamboo Data Center pricing options: Bamboo - Pricing | Atlassian

If you have questions regarding pricing, billing or licensing: Atlassian Support: Pricing, Billing, & Licensing | Atlassian

[Markus Sutter _Mibex Software_]

Thanks for the heads-up.

When is the release of Bamboo 9.6 planned?

[Anik Sengupta]

The date is tentative as of now,  14th march 

[Michael Rüegg _Mibex Software_]

Thanks for the info.

I assume this change has an impact on custom Bamboo tasks, because not every task can be made remote agent capable yet.

There are still a lot of missing Bamboo dependencies not available on remote agents.

For some of those, you can circumvent the issue by providing data you need in a build task in a RuntimeTaskDataProvider before the build, but for others, it is not easily possible. To give you two examples:

1. com.atlassian.bamboo.plan.artifact.ArtifactDefinitionManager: without access to this API, how can a build task on a remote agent get access to newly created artifacts during a build?

2. com.atlassian.bamboo.security.EncryptionService: without access to EncryptionService in remote agents, is the idea to put clear-text tokens into the RuntimeTaskDataProvider?

[Bob Swift {Appfire}]

It is bad that local agents were removed BEFORE 10.x - that is when it was expected, not on 9.x. 
Is there anyway to turn this feature back on with a property setting????

We have an extensive automated test suite and infrastructure all dependent on local agents. We cannot mark compatibility for 9.6 because of this withdrawal.

[Jeff Thomas]

@Michael Rüegg _Mibex Software_ I'm working internally to get answers on these examples, I'll update here when I have those. If you want, you can reach me at jeffjeff at atlassian dot com and I will open a support ticket on your behalf, which may be helpful if we have to gather additional information.

@Bob Swift {Appfire} Can you shoot me an email (jeffjeff at atlassian dot com) so that I can setup some time to discuss and understand your use of local agents?

Cheers!

[Michael Rüegg _Mibex Software_]

@Jeff ThomasThanks for reaching out.

We could at least solve the issue to make one of our Spring Scanner based Bamboo apps compatible with remote agents by using the new Spring Java Config.

The secret sauce is to use the annotation "BambooOnly" on the Scanner Config, which is only true on the Bamboo server, but not on remote agents. With that, the app does not fail when those missing dependencies are not available on the remote agent:

@Conditional(Array(classOf[BambooOnly]))

Hope that helps others as well.

What is still an issue is that Bamboo tasks on remote agents are limited due to the fact that important dependencies like EncryptionService are not available there.

[Marcin Gardias]

RE: exposing SecretEncryptionService to remote agents:

In its current form, EncryptionService absolutely must not be exposed to agents because that would mean exposing its master cipher over the network, unencrypted, so that agents can unencrypt whatever is encrypted with it. In other words, any security uplift would be purely illusory, in fact, security would be severely weakened.

The right way is to have remote agents communicate with the server over a secured channel.

We may consider adding a possibility of exchanging a cipher generated on per-agent basis and making it possible to encrypt data on the server _for a particular agent/build_ but ultimately, at some point cipher has to be exchanged _somehow_.