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

[Joe McCall]

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

[Przemek Bruski · Accepted solution]

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

[Joe McCall]

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

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

[Brian Begy]

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

[Brian]

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

[Ed Jackson]

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.

[ajtrichards]

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

[Brian Begy]

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

[Andrew Khoury]

Does an offical list exist yet?

[Mike Deeks]

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]

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]

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]

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]

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]

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

[David Cahill]

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]

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.

[Jesse Sanford]

When will this be fixed?

[Isaac Weathers]

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

[Michael Nielsen]

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]

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]

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.

[William Santa]

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

[Artjom Shymanovski]

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]

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.