How do I properly handle secrets with Bamboo 6.2 onwards

[Dnlhoust]

In Bamboo versions which support Specs, how do I correctly handle secrets in my build plans? Storing them in plain text in the repository seems like bad practice.

[Steffen Opel _Utoolity_]

Good question, the bootstrapping of secrets is a complex problem for configuration in code in general.

I'm not aware of a dedicated recommendation from the Bamboo team and would appreciate if they'd chime in as well, but here are two approaches that I'd consider at this point:

1. In line with the Twelve-Factor App's Config advise, configuration that varies should be stored in the environment. Accordingly, for contexts that allow the use of Bamboo variables (like tasks), you could store the secrets in an automatically encrypted 'password variable' - this behavior is not properly documented, but referenced from Defining global variables:

Note that if your new global variable contains the word 'password' then the value field will be automatically encrypted. If you change a variable to include the word 'password', then the value field will change from viewable text to an asterisk string.

You can then reference those Variables from Bamboo Specs.

• Using secured Environment variables is also the pattern recommended by the Bitbucket Pipelines team btw.

2. As a variation of the aforementioned pattern, you could also retrieve the secrets at runtime from an external service and then inject them into variables via a task, for example the built-in Bamboo Variables task.

Of course, this requires that your access to said service is in itself properly secured, which would apply for scenarios that can leverage securely stored credentials, for example Bamboos built-in Shared credentials, or third party apps like Identity Federation for AWS (Bamboo) (Disclaimer: I'm the co-founder of this app's vendor Utoolity).

[Dnlhoust]

Steffen, I appreciate your well thought out answer, especially since I posted this only a few hours ago.

I feel this question is best asked to the Bamboo team in a broad scope (I'd love some guidelines/best practices around specs!) but specially, I'm asking this question as a DevOps engineer trying to implement a Configuration as code solution using Bamboo Specs. 

In my specific case, I've used Bamboo variables within tasks, however I'm concerned that their encrypted form in Specs is usable cross plans. I found that Password/secret variables which are defined in the scope of one project result in the same encrypted values as the same Password/secret variable defined in another, suggesting you could copy encrypted values between projects, decrypt them, and expose the secrets.

I'm leaning towards your second suggestion, though I think setting up shared credentials requires admin on a project?

it seems strange to have rely on an external services here and I hope the Bamboo team can shed some light.

[Lars]

Also worth mentioning is the topic of restricting access to utilize the secrect in a task or similar. Be aware that some of the suggested solutions are "global" in nature, meaning that the secret can be utilized by anyone in Bamboo (anyone who can edit a plan).

Let's say you have secrets in Bamboo which are meant for deployment, not for build. However, you may have a fair amount of users which you allow to do build plans. In this case, I don't see how you can prevent a user who's meant only to be able to do build steps to actually take advantage of such secret, even though this shouldn't happen.

Bottom line:  Bamboo's build-in features for managing secrets take some steps to make it hard to utilize the secret outside of Bamboo, but doesn't help you in respect to who has access to make use of the secret inside Bamboo, i.e. in plans. 

[Boris Van Hardeveld]

@Dnlhoust I don't know how relevant this still might be to you after more than 2 years, but I have create a plugin which might be of interest. It essentially allows you to manage your secrets external to Bamboo, and refer to them using plain text. Please find it at https://marketplace.atlassian.com/1221965. I would really appreciate any remarks, questions or feedback you might have.

I hope this does not come across as spam. The reason I created the plugin is because it solves a problem which I was personally experiencing as well and is in my opinion left unsolved by the core Bamboo product.

[Lars]

Appreciate the plugin.

However, who has access those variables?  (with the secrets). Unless there's a way to limit access to those secrets from Bamboo then I don't see the attraction of plugin. You are just exposing what was previously a well-guarded secret in AWS Secrets Manager, HashiCorp Vault to the whole Bamboo installation in your org.

[Boris Van Hardeveld]

@Lars thank you for your remark. Please have a look at the following documentation: https://windtunnel.io/products/smb/#/topics/scoping. The plugin allows scoping a secret manager to any selection of projects, plans, deployments or environments. As such, it is possible to have a one-on-one relationship beween a Bamboo project and an external vault.

Of course, this works in tandem with the regular user and group based access controls already available in Bamboo.

Hope this makes it clear. If not, please let me know and I'll try to improve the documentation.

[Lars]

@Boris Van Hardeveld

Looks good. Exactly the type of restriction I was asking for.  :-)

Even though your plugin costs money I don't see it as a spam on this thread. It seems like a perfectly good candidate for a solution to the stated problem,

[Bill Wang]

* About solution one, to set Global variables will be not allowed in our company.  Second, it will be not easy way to manage, because we have about 3~5 different secrets variables for each build plan and we have hundreds and thousand plans

In previous way with normal bamboo plan, we manually create secret variables (PASSWORD_XXXX) for each bamboo plan.

* About solution two, it is not for secrets. because we don't want to save the key (whatever it is encrypted or not) in source codes. 

So seems this feature (bamboo yaml spec)  is still not ready for use.