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.
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).
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.
Bamboo 5.9 will no longer be supported after June 12, 2017. What does this mean? As part of our End of Life policy, Atlassian supports major versions for two years after the first major iteratio...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot