I have just installed Free Trial version "TASKS for AWS (Bamboo)" and "Identity Federation for AWS (Bamboo)", and we want to explore to use SAML 2.0-based Federation to provide the temporary credentials which enable use to fulfill the deploy tasks to AWS services like S3, Elastic Beanstalk, as well as other management tasks.
Following url explains what we are trying to realize around SAML-Based Federation:
Can someone shed some lights whether we can use upper-mentioned two Bamboo Apps to help out situations? either out of box or via some customization.
Thank you for evaluating our apps.
We currently only support the three AWS Identity and Access Management (IAM) based STS API actions to create temporary AWS security credentials, but neither AssumeRoleWithSAML nor AssumeRoleWithWebIdentity (or rather Amazon Cognito these days).
We have a backlog story covering SAML 2.0-based Federation, but it hasn't gained any traction yet and is thus not on our near-term roadmap:
As briefly outlined there, "We initially considered this to be out of scope, assuming anyone using SAML would rather use SSO with AWS directly then, and Atlassian didn't even support SAML until recently".
However, as your use case confirms, "This might have been shortsighted, insofar the main use case is retrieving AWS credentials for reuse in add-ons like Tasks for AWS [...]".
Accordingly, please watch and vote for this issue, ideally commenting with your detailed requirements to help us identify a path forward regarding this important feature for enterprise identity management:
In terms of a custom approach, you might be able to still use Tasks for AWS with SAML by means of providing temporary AWS credentials inline, rather than the usually preferable Identity Federation for AWS connector.
The key aspect is that the AssumeRoleWithSAML API action can be called without any AWS credentials, though you obviously need to provide a resp. SAML assertion that's valid for a sufficiently long duration. If you are able to do that, this would enable the following workflow:
I realize that this is neither as convenient nor as secure as desired, but maybe this allows you to explore the use case?
Thanks for the response and recommended workaround, I will definitely give it a try with Bamboo, though it is not the very straightforward one as we expected, as we thought there would be out-of-box solution with Identity Federation. However, we do like the explore the very rich features with Tasks for AWS so that we can easily manage AWS services.
To help you understand, following would be what we expect from Bamboo Plugin, similar to what we have today with Jenkins, which we have customized Jenkins plug-in to allow deploy jobs, based on given user ID/password and to-be-assumed AWS role arn, to obtain dynamically temporary AWS credentials ( AWS_ACCESS_KEY_ID, AWS_SECRETE_ACCESS_KEY, and AWS_SESSION_TOKEN) through calling STS token service, prior the call, AD (ADFS) will verify the user's credentials.
Not sure for Bamboo, the future Identity Federation will provide similar or have other options.
As to your recommended workaround, I will definitely give it a try and give your feedback. Thanks for the advice.
@Steffen Opel _Utoolity_ for Identity Federation for AWS Connector, can you direct me where I can find more info about the long term access user? I want to explore the requirement of such long-term user access on AWS and compare to what we are using today via Jenkins, through ADFS and STS, our AWS access are all role-based and for temporary usage.
If we use Identity Federation for AWS Connector, I guess the federated access will also be role based with temporary credentials, but for the long-term user used in connector, what should the permission and policy be defined? When bamboo's user is granted to assume the role, the permission and policy should be defined at AWS, right? Sorry, for the stupid questions, per least access policy, I don't see the full picture, especially for setup related to IAM.
My apologize for too much questions, but I want to be open to all options at this point. Our other option is customize Bamboo to interact with internal ADFS, STS, (and IAG) to allow legitimate users to assume the appropriate role, definitely not a a trivial task.
@Shao Cai sorry for the delayed response. There are no inappropriate questions btw., everything that's not self explanatory from the app or the docs surely comprises a usability issue that we need to improve upon! Besides, your understanding is spot on:
You should be able to conceptually retain your current approach and probably do not even need to change your existing roles on the AWS side of things.
If we use Identity Federation for AWS Connector, I guess the federated access will also be role based with temporary credentials, but for the long-term user used in connector, what should the permission and policy be defined?
Correct - the IAM user for the Identity Federation for AWS Connector that provides the long-term AWS credentials only needs permissions to call the AssumeRole API for the roles you want to use, here's a minimalist example policy (see also quickstart below).
Of course, you probably would replace the wildcard '*' role selector with specific role names in a tightly controlled production environment.
When bamboo's user is granted to assume the role, the permission and policy should be defined at AWS, right?
Correct - you can optionally also further restrict the permissions on the Bamboo side as per 4. below, which allows you to use fewer roles with broader scopes, yet provide more restricted permissions to specific Bamboo user groups, say for different projects.
I hope above answers are already sufficient to confirm your understanding, but to elaborate a bit, allow me to briefly walk through the Identity Federation for AWS core value proposition:
1. In accordance with AWS security best practice, all integrations should only use temporary security credentials when calling the AWS service APIs for the actual workload, say to create/update/delete a stack via the CloudFormation stack task.
2. Of course, there still needs to be a credentials provider to call the resp. STS API actions for temporary security credentials in the first place. At this point you need to configure one or more AWS access keys, though we have backlog issues to also support other providers like EC2 instance profiles, and as you know, SAML 2.0.
3. Once an access key is in place, you can configure one or more AWS connectors to generate the temporary security credentials at runtime.
4. You can optionally specify an IAM policy to further restrict the permission granted by the role as configured on the AWS side.
5. Finally you can configure which user group can use the connector when configuring tasks. Please note that due to Bamboo's architecture, the builds are executed without any user context at runtime, which may be a difference to how Jenkins operates.
We have a two CloudFormation templates that can Provision AWS resources to get started with Identity Federation for AWS:
I hope this clarifies things a bit, though I realize that it is still a lot to wrap your head around - please don't hesitate to contact us if you would prefer to discuss any details in private.
Hi Steffen, sorry for taking so long in my response. Here I want to tell you that we are happy with Bamboo especially its integration with other Atlassian tools which we are currently using. Now, the only ( as far as I can see) gap is: if we want to make Bamboo to support SAML2.0 based Federation access, will that be possible? I noticed that, as Background 5 says, "due to Bamboo's architecture, the builds are executed without any user context at runtime, which may be a difference to how Jenkins operates"
I will continue to contact you and discuss more in detail.
G’day Community! As we gear up to introduce Bamboo Data Center to the world, we wanted to make sure that we shared a bit more about Bamboo, the product. Our team has put together an overview video ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events