What permissions does the bamboo IAM user need for Elastic Bamboo?

Joe McCall March 15, 2013

Right now my bamboo user has 100% access to EC2, but I'd like to restrict it. What exact operations does Elastic Bamboo need to perform?

If it helps, here is the security policy for my current bamboo user in EC2:

{
  "Statement": [
    {
      "Action": "ec2:*",
      "Effect": "Allow",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "elasticloadbalancing:*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "cloudwatch:*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "autoscaling:*",
      "Resource": "*"
    }
  ]
}

12 answers

1 accepted

1 vote
Answer accepted
Przemek Bruski
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 15, 2013

An official list of EC2 IAM permission does not exist, sorry.

Joe McCall March 19, 2013

Cool. I'll try putting in a request for one in jira.

*EDIT: looks like this represents what I'm looking for.

Brian Begy June 22, 2014

Seriously? This issue has been open for TWO YEARS and still isn't fixed?

Brian April 27, 2015

Leaving a big security flaw like this open for so long makes makes Atlassian such a big target.

2 votes
Ed Jackson May 18, 2017

I have a slightly modified version of the above that uses a custom role instead of the Name tag. Maybe slightly more cumbersome in that you have to specify the role name in every Elastic Agent configuration, but the naming is completely under your control.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowBambooToStartNewBuildAgents",
            "Effect": "Allow",
            "Action": [
                "ec2:Describe*",
                "ec2:RequestSpot*",
                "ec2:CancelSpot*",
                "ec2:AllocateAddress",
                "ec2:AssociateAddress",
                "ec2:AttachVolume",
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CancelSpotInstanceRequests",
                "ec2:CreateKeyPair",
                "ec2:CreateSecurityGroup",
                "ec2:CreateTags",
                "ec2:CreateVolume",
                "ec2:DeleteVolume",
                "ec2:GetConsoleOutput",
                "ec2:ModifyInstanceAttribute",
                "ec2:ReleaseAddress",
                "ec2:RequestSpotInstances",
                "ec2:RunInstances"
            ],
            "Resource": "*"
        },
        {
            "Sid": "OnlyAllowBambooToTerminateBuildAgents",
            "Effect": "Allow",
            "Action": [
                "ec2:TerminateInstances",
                "ec2:StopInstances",
                "ec2:StartInstances"
            ],
            "Resource": "arn:aws:ec2:us-east-1:ACCT#:instance/*",
            "Condition": {
                "ArnEquals": {
                    "ec2:InstanceProfile": "arn:aws:iam::ACCT#:instance-profile/my-bamboo-agent"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::ACCT#:role/my-bamboo-agent"
        }
    ]
}

In addition to publishing an authoritative minimum-access policy, I'd sure like to see Atlassian update the EC2 integration. If my server is running in EC2, I shouldn't need to supply access credentials for a special user; I should be able to configure an instance profile for the server that supplies all required permissions.

2 votes
ajtrichards September 9, 2015

We used the following to get up and running with Bamboo. It's a mixture of the two examples above as there seemed to be some required permissions missing.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "BambooAllowedAll",
            "Effect": "Allow",
            "Action": [
                "ec2:Describe*",
                "ec2:RequestSpot*",
                "ec2:CancelSpot*",
                "ec2:AllocateAddress",
                "ec2:AssociateAddress",
                "ec2:AttachVolume",
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CancelSpotInstanceRequests",
                "ec2:CreateKeyPair",
                "ec2:CreateSecurityGroup",
                "ec2:CreateTags",
                "ec2:CreateVolume",
                "ec2:DeleteVolume",
                "ec2:DescribeAddresses",
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeImages",
                "ec2:DescribeInstances",
                "ec2:DescribeKeyPairs",
                "ec2:DescribeRegions",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSpotInstanceRequests",
                "ec2:DescribeSpotPriceHistory",
                "ec2:DescribeSubnets",
                "ec2:DescribeVolumes",
                "ec2:DescribeVpcs",
                "ec2:GetConsoleOutput",
                "ec2:ModifyInstanceAttribute",
                "ec2:ReleaseAddress",
                "ec2:RequestSpotInstances",
                "ec2:RunInstances",
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": "*"
        },
        {
            "Sid": "BambooAllowedOnlyOnCreated",
            "Effect": "Allow",
            "Action": [
                "ec2:TerminateInstances",
                "ec2:StopInstances",
                "ec2:StartInstances"
            ],
            "Resource": "arn:aws:ec2:eu-west-1:<YOUR_AWS_ACCOUNT_NUMBER>:instance/*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/Name": "bam::<YOUR_JIRA_CLOUD_URL>.atlassian.net::js-bamboo"
                }
            }
        }
    ]
}
2 votes
Brian Begy June 22, 2014

No, seriously. How do we run Bamboo in a least-privilege mode?

2 votes
Andrew Khoury May 18, 2014

Does an offical list exist yet?

1 vote
Mike Deeks June 11, 2015

This seems to work for me. This can probably be locked down even further but it is a huge pain to test this by trial and error. 

You can remove the iam:PassRole section if you don't use instance profiles (if you don't know what that is, then you don't  use it).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::*:role/elasticbamboo"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:Describe*",
                "ec2:CreateTags",
                "ec2:RunInstances",
                "ec2:RequestSpot*",
                "ec2:CancelSpot*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "ec2:TerminateInstances",
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/Name": "bam::acompli.atlassian.net::js-bamboo"
                }
            }
        }
    ]
}
Oliver Hagel-Doll September 7, 2015

Termination in this way does not work. It simply happens nothing. Is there a way to find out what's the reason for this?

Adalbert Wysocki September 8, 2015

I am not sure about this policy. If you let bamboo tag resources *, it can tag any instance with ''bam::acompli.atlassian.net::js-bamboo" and terminate it?

Mike Deeks September 8, 2015

Correct. Like I mentioned above, this can probably be locked down further. But this was the best that I could get working at the time. It helps prevent accidental termination from bamboo. It does not prevent someone who gets access to these credentials from overwriting your tags and terminating. Though they would have to guess that the restriction only applies to resources with a specific Name tag.

Mike Deeks September 8, 2015

Testing these things is very difficult and time consuming. If you find ways to lock this down further then please share with the rest of us.

Oliver Hagel-Doll September 8, 2015

Our present policy in comparison (I think you missed some important ones for the current Bamboo UI): { "Version": "2012-10-17", "Statement": [ { "Sid": "BambooAllowedAll", "Effect": "Allow", "Action": [ "ec2:AllocateAddress", "ec2:AssociateAddress", "ec2:AttachVolume", "ec2:AuthorizeSecurityGroupIngress", "ec2:CancelSpotInstanceRequests", "ec2:CreateKeyPair", "ec2:CreateSecurityGroup", "ec2:CreateTags", "ec2:CreateVolume", "ec2:DeleteVolume", "ec2:DescribeAddresses", "ec2:DescribeAvailabilityZones", "ec2:DescribeImages", "ec2:DescribeInstances", "ec2:DescribeKeyPairs", "ec2:DescribeRegions", "ec2:DescribeSecurityGroups", "ec2:DescribeSpotInstanceRequests", "ec2:DescribeSpotPriceHistory", "ec2:DescribeSubnets", "ec2:DescribeVolumes", "ec2:DescribeVpcs", "ec2:GetConsoleOutput", "ec2:ModifyInstanceAttribute", "ec2:ReleaseAddress", "ec2:RequestSpotInstances", "ec2:RunInstances", "s3:GetObject", "s3:ListBucket" ], "Resource": "*" }, { "Sid": "BambooAllowedOnlyOnCreated", "Effect": "Allow", "Action": [ "ec2:TerminateInstances", "ec2:StopInstances", "ec2:StartInstances" ], "Resource": "arn:aws:ec2:eu-central-1:111111111111:instance/*", "Condition": { "StringEquals": { "ec2:ResourceTag/Name": "bam::geioshq.atlassian.net::js-bamboo" } } } ] }

1 vote
David Cahill June 3, 2015
If your cloud infrastructure EVER gets hacked, someone will have full permission to all of EC2 for every single one on your customers...
Is this really such a small deal to you that you cannot provide a WRITTEN policy to recommend to users in order to run their bamboo agents in AWS.
Please get something together. All other major companies do this today. Look at Cloudability for instance.
This also puts you, and any customers who run this in the suggested way, in violation of several serious compliance regulations, including PCI.
It's been 3 years. This is ridiculous guys. These are MAJOR issues.
I'm currently having to hack around this in order to make sure we meet compliance. (Plus I won't let your internal employees have full access to our EC2 account.).


One quick REAL WORLD EXAMPLE situation for you, as I know "hackers" seem impossible until it's too late for some people. So how about this situation:
An ATLASSIAN developer accidentally pushes a commit to production that effects the Bamboo automatic instance scaling system. Due to the difference of comma out of place in an array, the conditional evaluator for what instances should be TERMINATED when a bamboo agent stops running breaks. The system then believes all EC2 instances have had their agents shut down and it's way over it's max limit. So is terminates all EC2 instances.
How many customers would lose data do you think in this situation?
Improbable?... look here, this is on my screen right now:
Elastic Bamboo Error : EC2 Instance i-8xxxxxxx is in an unrecognised state: UNKNOWN: Failure in EC2 instance i-8xxxxxxx.  Attempting to terminate.

While I have the experience needed to work around this. 99% of developers and system administrators will NOT.
That's why this issue doesn't have a lot of vote.
But please hear me when I say this. Votes have NOTING to do with how important many of your issues, bugs, security fixes and features requests are. I hope you can get people in soon to evaluate this and other requests.
Thank you, I don't mean to come off harshly. But this is very important.
--David Cahill
Senior Systems Security Engineer
Malwarebytes
Mike Deeks June 24, 2015

Strongly agree. I did a lot of the hard work for them. I posted a stronger policy above. It restricts what can be terminated and minimizes what API calls it can execute. Unfortunately Amazon has limits on resource level permissions so I cant restrict it much further than that.

1 vote
Jesse Sanford August 9, 2014

When will this be fixed?

0 votes
Isaac Weathers August 17, 2018

Do any of these solutions provide for using SPOT instances within Bamboo for ElasticBamboo. All of my tests for using this have failed. 

0 votes
Michael Nielsen August 3, 2018

Am I correct in my understanding from seeing that this has been dangling for 5 years that Atlassian is not really very committed to providing proper EC2 support?

Jeyanthan I
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 3, 2018

I understand you are looking to know the minimum access policies required for Bamboo Server to be able to work with elastic agents. Please correct me if I understood your requirement wrong. I see that one of the comments have a full list of EC2 actions used by Elastic Bamboo.

These actions must be included in any minimal / customized security policy for the Elastic Bamboo user you're using to authenticate with EC2 for the functionality to work. As you see, the feature request BAM-11932 is already tracking this.

Cheers,
Jey

Michael Nielsen August 3, 2018

I didn't get the impression that the policy provided by @Ed Jackson was the official list.

Also, BAM-11932 has been open for 6 years, so maybe I'm wrong, but I have my suspicions that a solution won't be forthcoming any time soon.

0 votes
William Santa November 11, 2015

@Alex Richards - Thanks. This cleaned up version came in very handy.

0 votes
Artjom Shymanovski June 23, 2015

How we can create a user for Bamboo to access instances of only one VPC?  I have 3 VPC: Dev, Test, Prod . Now I want to give access for Bamboo to Test EC2 . Is it possible?

Mike Deeks June 24, 2015

AWS does not let you restrict many of the API calls. DescribeInstances for example can not be restricted in any way: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ec2-api-permissions.html#ec2-api-unsupported-resource-permissions Restricting what the bamboo user can terminate is basically the best you can do. See my policy I posted above. My policy only allows bamboo to terminate instances that match the name bamboo uses for elastic instances.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events