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

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": "*"
    }
  ]
}

10 answers

1 accepted

1 votes

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

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

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

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

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

Does an offical list exist yet?

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

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"
                }
            }
        }
    ]
}

When will this be fixed?

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

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.

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"
                }
            }
        }
    ]
}

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

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?

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.

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.

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" } } } ] }

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.

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?

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.

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

Suggest an answer

Log in or Join to answer
Community showcase
Renan Battaglin
Published May 18, 2017 in Bamboo

FAQ: How to Upgrade Bamboo Server

Bamboo 5.9 will no longer be supported after June 12, 2017. What does this mean? As part of our End of Life policy, Atlassian supports major versions for two years after the first major iteratio...

1,075 views 0 5
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot