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.
* 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.
Welcome to your weekly Jira Ops Early access program update, where we’re sharing news and updates on Jira Ops' progress as we work toward our 1.0 release. If you ever want to drop us feedback or idea...
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