Best practices for Bamboo security

Still need help?

The Atlassian Community is here for you.

Ask the community

The best way to harden a system is to look at each of the involved systems individually. Contact your company's security officer or department to find out what security policies you should be using. There are many things to consider, such as the configuration of your underlying operating systems, application servers, database servers, network, firewall, routers, etc. It would be impossible to outline all of them here.

 

This page contains guidelines on good security practices, to the best of our knowledge.

On this page:

Configuring the web server

Please refer to the following guides for system administrators:

Configuring the application server

See the following system administrator guide for general hints on the application server level:

Configuring the application

The way you set up Bamboo roles, permissions and processes makes a big difference in the security of your Bamboo site.

Below are some more Bamboo-specific items to consider. None of these provides 100% security. They are measures to reduce impact and to slow down an intruder in case your system does become compromised.

  • Restrict the number of users with powerful roles or group memberships. If only one department should have access to particularly sensitive data, then do restrict access to the data to those users. Do not let convenience over-rule security. Do not give all staff access to sensitive data when there is no need.
  • Put documented procedures in place for the case of employees leaving the company.
  • Perform security audits regularly. Know who can help in case a security breach occurs. Perform 'what if' planning exercises. ('What is the worst thing that could happen if a privileged user's password were stolen while he's on vacation? What can we do to minimize damage?').
  • Make sure the Bamboo database user (and all datasource database users) only has the amount of database privileges it really needs.
  • Monitor your binaries. If an attacker compromises an account on your system, he will usually try to gain access to more accounts. This is sometimes done by adding malicious code, such as by modifying files on the system. Run routine scripts that regularly verify that no malicious change has been made.
  • Disable Bamboo from serving HTML and JavaScript artifacts. Allowing Bamboo to do this creates an XSS vulnerability where HTML and JavaScript artifacts can be executed on the user's browser. Go to Security settings (under 'Security') in the Bamboo admin area, and clear the Resolve artifacts content type by extension checkbox. Such artifacts will then be returned as plain text resources and the user's browser will handle them as simple text.

Securing JGit connections

Use the bamboo.crypto.trust.jgit.all system property. The default value is "true", which means that the application maintains the old logic when AllTrustingHttpConnectionFactory is used for JGit connections. You can override this property by setting the value to "false", which means that org.eclipse.jgit.transport.http.JDKHttpConnectionFactory will be used for certificate validation.

This feature addresses the issue mentioned in  BAM-16194 - JGit allows Bamboo agents to trust any given certificate OPEN .

Configuring system admin access

Below are some things to consider specifically related to the system admin role:

  • Keep the number of Bamboo administrators extremely low. For example, 3 system administrator accounts should be the maximum.
  • The administrators should have separate Bamboo accounts for their administrative roles and for their day to day roles. If John Doe is an administrator, he should have a regular user account without administrator access to do his day to day work (such as configuring build plans). This could be a 'john.doe' account. In addition, he should have an entirely separate account (that cannot be guessed by an outsider and that does not even use his proper name) for administrative work. This account could be 'jane smith' – using a username that is so obscure or fake that no outsider could guess it. This way, even if an attacker singles out the actual person John Doe and gets hold of his password, the stolen account would most likely be John's regular user account, and the attacker cannot perform administrative actions with that account.
  • Lock down administrative actions as much as you can. If there is no need for your administrators to perform administrative actions from outside the office, then lock down access to those actions to known IP adresses, for example. See Using Apache to limit access to the Confluence administration interface for guidance.

Further precautions

As another precaution:

  • Regularly monitor the above requirements. There are many things that could start out well, but deteriorate over time:
    • A system may start out with just 3 administrators, but over the course of a year this could grow to 30 administrators if no one prevents expansion.
    • Apache administration restrictions may be in place at the start of the year, but when the application server is migrated after a few months, people may forget to apply the rules to the new system.

Again, keep in mind that the above steps may only be a fraction of what could apply to you, depending on your security requirements. Also, keep in mind that none of the above rules can guarantee anything. They just make it harder for an intruder to move quickly.

Last modified on Aug 30, 2017

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.