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

Question

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

Shao Cai · Answer

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

Shao Cai · Answer

@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

Steffen Opel [Utoolity] · Answer

@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