Document minimum IAM permissions for using in an automated workflow

[jemisonf]

Hi! Huge fan of this tool. One issue I was running into using it is that the service account I'd set up previously for ECS deploys didn't have the right set of IAM permissions for and some of the operations that this script does failed with confusing error messages. Figuring out which permissions were required took a little trial and error, so I was thinking it might be useful to document specifically which ones are needed. What I currently have is:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ecs:ListServices",
                "ecs:UpdateService",
                "ecs:ListTasks",
                "ecs:RegisterTaskDefinition",
                "ecs:DescribeServices",
                "ecs:DescribeTasks",
                "ecs:ListTaskDefinitions",
                "ecs:DescribeTaskDefinition"
            ],
            "Resource": "*" # this should be locked down more ideally
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": <task role>
        },
        {
            "Sid": "VisualEditor2",
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::<id>:role/ecsTaskExecutionRole"
        }
    ]
}

Happy to write a PR to update the README but wanted to check first if I was missing anything in the list of actions in particular.

[fabfuel]

Hi!

Thanks a lot for the praise and for sharing your investigation results. I totally agree, that this is a common issue when starting with the tool and/or ECS. And I do not stop encouraging people defining as strict/specific IAM policies as possible, rather than using e.g. the managed AmazonECS_FullAccess policy.

The only thing is, that I would prefer linking to the AWS or ECS Documentation rather then defining an example policy here, because a) ECS might evolve and additional permissions might be required and b) it depends on the overall IAM strategy how policies and roles are configured and managed within AWS. For example, the role you are referring to only exists in your account (btw, you are exposing your account id 😬).

There are a couple of example policies in the AWS docs, did you check them out? https://docs.aws.amazon.com/AmazonECS/latest/userguide/security_iam_id-based-policy-examples.html

I think it would be very helpful, to share the list of permissions required (the Actions in your first statement) in the README as a hint (like which permissions are required "as of now") but I would not provide a full IAM policy, but link to the AWS documentation instead. I already imagine the support requests, why the shared policies are not working in 100% of the cases 🙂

What do you think?

Best Fabian

[jemisonf]

btw, you are exposing your account id 😬

Yikes, fixed! Thanks for catching that.

I think it would be very helpful, to share the list of permissions required (the Actions in your first statement) in the README as a hint (like which permissions are required "as of now") but I would not provide a full IAM policy, but link to the AWS documentation instead. I already imagine the support requests, why the shared policies are not working in 100% of the cases 🙂

I like this idea, that would have been perfect for what I was trying to do yesterday. It gives some more flexibility around describing the required iam:PassRole permissions too, since that would be confusing to try to write out in JSON in a way that's actually generally applicable for users.

I can work a PR for this next week, should be quick but I'm currently out on break for the US thanksgiving holiday.

[fabfuel]

That would be great, highly appreciated. Happy Thanksgiving!