@BASM Ltd,

Ah, now I see. Yes, it is a security problem. And I know, for as a Bamboo admin, I have used that capability to determine login information for an agent machine while the person who controlled it was on vacation. Anyone could do it. But (and this is nothing more than inconvenience) a non-admin would have to know which custom capabilities belonged to that particular agent.

Cheers Eddie, your plugin sounds just the ticket. 

Many thanks

Paul

paul981668836 it is admittedly less useful now with dedications, but my free Group Agent plugin was created to solve just the challenge you mentioned.

Agents can be denoted as a reserved agent via a new Group Agent capability.  Only plans that specific that agent by name are allowed to use it.  (in our company only authorized admins can manage that aspect of build configuration )   Deployments can optionally inherit the rules specified by the build plan, or allow any deployments.

https://marketplace.atlassian.com/plugins/com.edwardawebb.bamboo-group-agent/server/overview

Hi @Bill Cernansky, that would be fine if you could switch off / disable the standard capabilities for an agent. As far as I can see there is no means of stopping somebody creating a deployment plan with a script task (rm -rf *) and running that on any agent.

I feel like this was a good addition, but frankly, controlling things like this with custom capabilities is super easy. We have 1000+ plans on many many agents, and it all works seamlessly and with little effort to set up.

Referring back to the comment made by Adam Myatt on this ticket on 19/Sep/2011 

"When large companies have multiple subdivisions or many teams, sometimes those teams perform work that is sensitive in nature and they do not (and in some cases cannot) have people from another team or subdivision running their builds on their agent."

Being able to assign a deployment plan to run on any agent without enforcing any constraints is really bad news.

paul981668836, you can assign agent to any plan or deployment. It's not bypass, it's by design

For Bamboo Deployment plans it is still possible to select any individual agent. This appears to bypass all checks to limit an agent to specific plans.

I assume this is only configurable at a Bamboo administrator level - not at the plan level?

Great stuff! This is a big improvement over the previous way of doing things via capabilities / requirements.

Is there any news regarding the "Agent Prerequisites" features? This would be immensely useful in the case when you want an agent to NOT pick up the plans/jobs by default – which is quite common if you're doing multi-platform builds.

As an example, consider a case where you have a Linux cluster (local agents) and a Windows cluster (remote agents). You want most of the jobs to run on Linux by default, but some build plans would also have a Windows job that generates win32 artifacts. The question is – how do you prevent Windows agents from picking up arbitrary jobs by default (and only run jobs upon explicit request)? As of 5.5, you would have to add a "platform" agent capability and define it for each and every single job in each and every build plan which is extremely tedious. As of 5.6, you would be able to dedicate some of the Windows agents to some of the jobs that they have to run, but then you (a) essentially don't have a scheduler over a Windows cluster anymore since you assigned jobs to static agents (b) this is still quite clunky. If, on the other hand, it was possible specify agent prerequisites, then this whole problem is solved by just adding a custom requirement to any Windows job and it would be scheduled to run on one of the remote agents.

I hope this makes sense.

Thanks.