You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Speak of work around, as to providing temporary AWS credentials inline, I am not seeing the choice of "inline" available for me, see attached below for screen-shot, the only I can see is one for Federation and the other for EC2 IAM Role". I tried from "AWS Credentials Variables Configuration" Task.
I just recently downloaded "task for aws" plugin, it is Version:2.18.2. Am I missing any other plugin or this is not the latest version?
Thanks very much.
Thanks for the detailed inquiry, much appreciated. You are not missing anything, unfortunately I've not been precise enough when I described the potential workaround on the referenced question, which turns out to be slightly misleading and surfaces a usability issue, sorry about that:
All our AWS integrations like Tasks for AWS (Bamboo) and Automation with AWS are using another app Identity Federation for AWS as a shared component to provide temporary AWS credentials at runtime (it's included for free, which works automatically).
However, Identity Federation for AWS also provides additional features on its own, for example the AWS Credentials Variables task that you used to explore the workaround.
Now, given that app's core value proposition is to provide temporary AWS credentials for others, we considered it inappropriate to also offer the use of the older 'inline' credentials variation there, because using long-term AWS credentials directly is at odds with the security best practices we aim to promote (back then we didn't offer the 'Provide session token variable' option).
Inline security credentials
Long story short, the inline AWS security credentials option referenced in the workaround is available for all tasks in Tasks for AWS (Bamboo), except for those provided by Identity Federation for AWS (Bamboo) - here's how the credentials section looks for the former (e.g. the CloudFormation task):
I hope this helps to get you going - please don't hesitate to contact us directly in case you prefer to discuss any details in private.
@Steffen Opel _Utoolity_ Thanks so much. I tried the inline for AWS Security Credentials, and it worked, at least, for the cases I tried via S3 operations.
For the purpose of POC, it is okay to inject credentials for each task, however, to promote the solution, we at least want to have one place to inject credentials. So, inject once at one place, used for all tasks.
I recall in some posts that, you mentioned that, bamboo credential variables name are significant, so do we have any way to set the credentials variables which can be automatically used by all tasks?
Regardless, I am happy that I have progressed so much that I can explore all the AWS tasks to provide enough show cases for the decision-making.
Thanks for the help!
@Shao Cai - glad you got this to work!
We have a page documenting the general approach of Injecting task configuration via Bamboo variables (which btw. not only works for credentials, but also most other parameters, thereby providing one of three options to Providing task configuration as code).
The main takeaway is that you can achieve variable reuse across tasks by providing either global or plan level Bamboo variables so that you can reference the same variable names in each task and only need to update the variables in one place.
The only relevant naming constraint is that you should add the magic phrase "password" to variables containing sensitive information so that they will be masked with "********" in the build logs (this is unfortunately not mentioned in the official docs).
For example, we have defined the following global variables in our related test scenarios (the access key ID is not considered a secret, but you could also mask it of course):
You would then use these variables from our tasks via the following references (note the 'bamboo' prefix required here):
I hope this helps to simplify your workaround, and also illustrates using variables for general configuration reuse in Bamboo builds and deployments.
That being said, the main value proposition of our Identity Federation for AWS apps is to provide a secure and convenient way to use temporary AWS credentials derived from centrally managed long-term credentials so that you do not need such workarounds via variables at all - I'll provide an answer to your resp. follow up question later today.