About SAML 2.0-based Federation and Bamboo's solution for AWS deployment

[Shao Cai]

Hi There, 

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:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html

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. 

Thanks

Shao

[Steffen Opel _Utoolity_]

Hi Shao,

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 an administrator, I want to facilitate the AssumeRoleWithSAML API so that I gain AWS access via SAML based enterprise identity solutions (UAA-269)

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 particular, Bamboo jobs run without a user context, how would you expect the SAML federation to work in this regard? For example, right now users need to provide at least one set of long-term AWS credentials, which are then used by Bamboo at runtime to derive non user-specific temporary credentials (in contrast to the SSO links in the AWS Resources menu, which use impersonation).

Potential Workaround

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:

1. provide the SAML assertion via a Bamboo variable
2. use the AWS CLI's assume-role-with-saml to create temporary AWS credentials
3. inject new Bamboo variables based on those temporary AWS credentials
4. use these Bamboo variables as inline AWS credentials in subsequent tasks

I realize that this is neither as convenient nor as secure as desired, but maybe this allows you to explore the use case?

Cheers,
Steffen

[Shao Cai]

Hi Steffen, 

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. 

Thanks

Shao

[Shao Cai]

@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. 

Thanks 

Shao

[Steffen Opel _Utoolity_]

@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.

Questions

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).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "sts:AssumeRole"
      ],
      "Resource": [
        "arn:aws:iam::account-id:role/*"
      ],
      "Effect": "Allow",
      "Sid": "STSAssumeRole"
    }
  ]
}

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.

Background

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.

• As documented for the resp. AssumeRole API action, the resulting session's permissions are the intersection of the role's identity-based policy and the session policies, i.e. You cannot use session policies to grant more permissions than those allowed by the identity-based policy of the role that is being assumed.
• At this point the policy needs to be specified inline, but the upcoming release 2.12 will also support the recently released STS support for managed policies (see quickstart below).

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.

Quickstart

We have a two CloudFormation templates that can Provision AWS resources to get started with Identity Federation for AWS:

• The 'core' managed policy is semantically required to cover all supported STS API actions, though as mentioned, you may want to restrict it to grant 'AssumeRole' permissions only for specific roles in production scenarios.
• The 'core' role covers the permissions for all Identity Federation for AWS integrations, which besides IAM/STS is just ECR at this point.
  • Please note that this Identity Federation for AWS role and policy does not cover Tasks for AWS, i.e. you would need to attach appropriate managed (or inline) policies for all tasks you want to use (we should obviously follow up with a resp. Tasks for AWS template accordingly).
• The 'quickstart' template also provisions an IAM user and access key for the long-term credentials that can assume the provisioned core role, but you probably want to do that within your own processes anyway.

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.

Cheers,
Steffen

[Shao Cai]

@Steffen Opel _Utoolity_  thanks for the info. I guess I will need a little more time to understand the approach and the weigh in our priorities, I will get back to you if we want to proceed with this option. 

Thanks

Shao

[Shao Cai]

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.

Thanks

Shao