@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.

Leaving on a high note James Dumay [Atlassian]!

(like)

Leaving on a high note jdumay!

Awesome news! Can't wait to check it out.

This problem just popped up for me after installing a remote agent for iOS builds. Other builds starting running on the remote agent and filing due to missing files. It took a little bit to figure out why every few build and deploys were failing. i felt as though after I installed the remote agent it should have asked to enable it for certain projects/plans instead of just opening it up for all.

This is issue is a major impediment my company broadening our use of Bamboo. Setting up multiple Bamboo servers just to partition the agents is not feasible. Developers should have full control of their respective plans and administrators should be able to restrict their plans to certain sets of agents at creation time. Why has this issue lingered for 5 years?

I should be clear that I do not offer any warranty of any sort for the code. Your mileage may vary, etc... Please report success or failure via github issues / stars

I have posted the code on github. I found the whole Atlassian ghetto too hard. The code works with 4.4 and is in production for us. If it fails with other versions please open an issue on the github repo.

https://github.com/raymcdermott/bamboo-remote-agent-acl

your plugin even. sigh

Bump, any update on this.

@ray.mcdermott@toyota-europe.com any chance you could bitbucket that code for you bucket. I mean anything would be great to allow better admin, instead of relying on developers to remember to set Job Requirements to limit there Agent. I want to take the guess work out of it.

Any idea when this will be implemented?

Ray, have you had a chance to upgrade your plugin yet?

Ray - would be keen to try out the plugin. I'm surprised that this is such a long running request. The ability to tie a job to an agent in Jenkins was the primary way we used it for deployment to certain dev and uat environments, and really missing the ability in testing a bamboo rollout.

Fair point - it was not a concern for us. It won't be hard to change for local agents to be restricted too. I plan to do the plugin next week so I will see if I get time to adapt / test. Otherwise I will add it as the first feature request

@ray.mcdermott@toyota-europe.com Is it necessary to limit the functionality to remote agents? There are compelling reasons why one would want to restrict a group of builds to a particular local agent. I would argue that your plugin could be more widely beneficial if you leave that restriction choice to the user.

I would be interested also, thanks for offering to publish the code!

I would be interested in this Ray. Thanks for your effort in this!

I wrote a plugin which reads two properties:

• controlled agents (comma sperated list of regexes that correspond to agent names)
• allowed groups (comma separated list, regexes not supported)

During the build pipeline it checks if the agent is a remote agent (local agents are not interesting). If so, the plugin checks if the agent is in the controlled list. If the agent is in the controlled list the user id is checked against the permitted groups.

It does not support dependent builds since Bamboo does not propagate the user ID.

Would anybody be interested? If so I will publish the code.

scott@mimicsimulation.com I'm pretty sure I had remote agents in mind when I created this issue (4 years ago). But I will update the description to note local/remote/elastic agents (all and every agent).

I notice that this issue implies that it would only be for local agents? Say it ain't so! I cast my vote for this, but I really want it to work with remote agents, because we don't actually use local agents....
So, I whole heartedly vote for this, but please make it remote-agent-compatible!

What's the status of this feature request? I am currently testing 5.0 Beta and it seems you can now tie dedicated agents to Deployment Environments, but not to actual Plans. Is this going to be fully implemented in 5.0 before final release or do we need to wait for another major release?

This is becoming critical for my business. We are having serious security concerns which might limit our ability to keep using Bamboo. We must be able to isolate builds to specific agents and vice versa.

Just wanted to express our desire for this enhancement so that Bamboo could better support enterprise usage – a single build server that supports multiple "teams", with appropriate isolation between teams. Being able to limit an agent to a particular team or group of plans would be very beneficial, particularly when it comes to Maven and it's settings.xml file that contains credentials needed to access/deploy to repositories and other servers. The additional security this feature would provide would be greatly appreciated! (We only need 1 JIRA server and 1 Stash server, we would like to only need 1 Bamboo server as well...)

this plugin https://marketplace.atlassian.com/plugins/com.edwardawebb.bamboo-group-agent solved my problem!!

This is something I'd definitely love to see. Some of our legacy products was only meant to build on 32 bit systems and aren't really designed to take in a 32bit compilation flag on a 64 bit system... At this moment for that issue specifically we just use a supports32bit and supports64bit with a true/false value.. but I find that personally pretty messy

Any update (or best guess) on an implementation timeline for this feature?

I believe some of our competitors have this, so it would be a good idea to implement.

Hi Adam,
There isn't a solid plan to implement this feature in the short term. However, it is likely that we review this ticket for inclusion into a release in the next year.

Thanks
James Dumay

Any update (or best guess) on an implementation timeline for this feature?

Any update (or best guess) on an implementation timeline for this feature?

Restricting an agent from running any kind of plan is an important feature for us.

We have a central Bamboo instance where teams have agents for their particular infrastructure. This allows them to run integration testing through the central web interface. We want these agents to run only these plans, and limit other plans from running on these agents. We have other agents for general purpose building.

Having multiple Bamboo instances is not an option for us.

Hi Clay,

At the moment, we do not have a concrete date for the delivery of this feature.

However, we know this is very useful and we would like to do this in the next 6 months. Without making false promises, it is difficult for me to be more specific that this.

Cheers,
Anton

I would like to know where this feature sits in the project queue? We have thousands of developers and hundreds of projects. I can't completely migrate everyone and every project from cruise control to Bamboo because of the inability to restrict build plans to specific agents.

>>You can always start with a single Bamboo instance, but at least keep an open mind towards breaking it up in the future

That's the plan. Thanks for your advice.

This is turning more into a support request So if we keep talking for much longer we should probably open a support request.

May I ask how many teams you plans to have using the Bamboo instance and how large each team is?

If a team has about 15-20 people and are very serious about CI, i.e. they plan to have about 30 plans to start with and then keep going, then I would suggest to setup a separate instance for each team, purely from a flexibility perspective for each team.

Having a team have full control over their CI environment without having to think about how any particular change will affect other teams helps development speed a lot.

You can always start with a single Bamboo instance, but at least keep an open mind towards breaking it up in the future

True, but we're intending to have one large Bamboo server as the primary starting point (main server for projects with local agent disabled) and numerous remote Bamboo Agent Servers. In this configuration, we currently cannot limit which plans execute on which agent servers.

Thanks for the update, Adam!

The ability to restrict which plans can execute on which agents is exactly what this feature request is all about.

Per my understanding, even if we setup different Bamboo agent servers for each team, we still cannot PREVENT plans from running on them, at least not with the current Bamboo 3.2 system, without modifying as you proposed.

A Bamboo agent is connected to only one Bamboo server. So an agent does not run plans from multiple servers. Therefore by making sure that certain plans exist on only certain Bamboo servers, and then ensuring that a server only has certain agents, it is possible to control what builds run where.

I beleive that meets the requirements of preventing an agent from executing builds that come from another Bamboo server.

Pelase let me know if I am misudnerstanding he scenario or missing something.

Cheers,
Anton

Anton, Thanks for getting back to me so quickly.

Regarding your comments

>>Is what you would like to see the ability to configure Bamboo such that Plan A can execute on Agent-Server-A if triggerred by user A, but cannot execute there (e.g. can only execute on Agent-Server-B) if triggerred by user B?

Yes, but based on your comments I would say it should be Plan-based, not user permission-based. A Bamboo Admin should be able to select which Plans can execute on a specific Agent, thus preventing all other Plans from executing on that Agent-Server. My end goal is to prevent anyone or any Plan from executing on an Agent Server unless so granted by a Babmoo Admin (whether that's controlled at the User, Group, or Plan level).

>>1.Setup a different Bamboo instance for each team. The flexibility given to each team, especially if they are of moderate size is worth it

Per my understanding, even if we setup different Bamboo agent servers for each team, we still cannot PREVENT plans from running on them, at least not with the current Bamboo 3.2 system, without modifying as you proposed.

>>2.Run each remote Bamboo agent as a separate OS user with file permissions configured such that each user cannot see another user's files

This sounds like the approach we'd take if we needed to run multiple agents on one OS. We were intending to run one agent per OS (by spinning up one virtualized OS per agent server). Either approach is just a question of maintenance, but either way, without an ability to prevent all but a specified list of Plans from running on Agents, the same security issue is present. If we can specify one or more Plans to run on a specific Agent (and thus prevent all other plans from running on it) this gives us an incredible amount of flexiblity and security.

One additional use case that is very important is that if you implemented the ability to restrict Plans on Agents, we could use Bamboo for building U.S. Export Control projects, which many organizations in my company work on. With Bamboo as it is, we cannot allow Plans that deal with code/artifacts that are Export Controlled to execute on an agent build server as Plans that have users that are not able to work with Export Control. If we can restrict which Plans can execute on which Agent Servers, then we can have several Agent Servers that deal execlusively with Export Control projects.

Adam,

I would really like to understand your usecase and what functionality you are after to ensure I am not misunderstanding your requirements.

Cheers,
Anton

Adam,

I really would like to understand what functionality you are after, as at the moment I am a bit confused.

Is what you would like to see the ability to configure Bamboo such that Plan A can execute on Agent-Server-A if triggerred by user A, but cannot execute there (e.g. can only execute on Agent-Server-B) if triggerred by user B?

How will this work if the triggerring is not manual but is due to code committed to a code repository?

Generally, user permissions per agent is not what we plan to implement. With every extra bit of flexibility usually comes complexity which eventually leads to a product that people really stuggle to understand. In this case it feels like the trade off between flexibility and complexity is not worth it.

As mentioned on BAM-7386 to achieve file security around each agent a couple of approaches are:

1. Setup a different Bamboo instance for each team. The flexibility given to each team, especially if they are of moderate size is worth it
2. Run each remote Bamboo agent as a separate OS user with file permissions configured such that each user cannot see another user's files
3. Setup each agent in a VM such as KVM

Cheers,
Anton

Regarding restricting plans to run on certain agents... I would like to add to the commentary. It would be very valuable, especially to large companies, to be able to restrict which agents a particular plan can run on based on users/groups. The use case is this:

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. One of the reasons behind this is the insecurity of a build server in general. If Team-A and Team-B run builds on Agent-Server-A, then Team-A can write some Java code that executes as part of their build via an Ant task. The java code can easily troll through directories on the agent server and read/discover the source code from Team-B's project. Obviously you would think this wouldn't be the case, but in today's world of tight security and modern hacker threats, you have to protect your source code as much as possible.

You would want a security option where the Bamboo admin can assign Team-A (via group membership perhaps) to be able to execute builds on Agent-Server-A, and Team-B to execute builds on Agent-Server-B. It may also be acceptable for Team-C to run builds on Agent-Server-B if Team-B and Team-C are part of the same organization/department (but that is up to the Bamboo admin to determine).

Not allowing this security feature will significantly prohibit some large globally distributed companies from making use of Bamboo and its Agents.

The plan (so to speak) is to allow people to limit agent to plans only. If we need to do more, we can match on more. Having pre-requisites based on properties of a plan could be useful, but it adds a level of indirection for the user that would add complexity for them. Unless we think it'll be a massive blocker for making this feature useful, we should stick to limiting an agent to a fixed set of plans.

Plans have requirements, agents have capabilities. How do we call the features we implements here? Prerequisite/property or somehow different?