Add Fargate/Lambda/IAM post

This commit is contained in:
Rob Watson 2018-01-30 15:34:56 +00:00
parent b6c5e4c59d
commit 40b79f5382
1 changed files with 49 additions and 0 deletions

View File

@ -0,0 +1,49 @@
---
title: Launching Fargate instances from AWS Lambda
slug: aws-lambda-ecs-runtask
layout: post
categories: aws serverless
date: '2018-01-30 01:00:00 +0000'
---
Over the last few days, I've been experimenting with serverless web application development. This has included testing out [Fargate](https://aws.amazon.com/fargate/), Amazon's new managed container deployment service, and the more established [Lambda](https://aws.amazon.com/lambda/) and [API Gateway](https://aws.amazon.com/api-gateway/) services.
The end result that I've been trying to achieve is to use Lambda to launch, via an API Gateway endpoint, a one-off asynchronous container execution on Fargate. So far, I've managed to put most of the jigsaw pieces together with only one major blocking experience.
The problem was giving the Lambda execution role the requisite permissions to launch ECS instances (which can include Fargate instances) automatically. There are a couple of blog posts on the subject out there, and [one in particular](https://lobster1234.github.io/2017/12/03/run-tasks-with-aws-fargate-and-lambda/) that states that the Lambda role needs two policies: one that allows the `ecs:RunTask` action on the relevant resources, and another that adds the `iam:PassRole` that allows the `ecs:RunTask` role to be passed onto the task execution service itself.
This seems reasonably clear, but several hours of trying to make the [Visual Editor](https://aws.amazon.com/blogs/security/use-the-new-visual-editor-to-create-and-modify-your-aws-iam-policies/) apply the policies correctly I was still receiving permissions errors when Lambda tried to launch the Fargate container.
```
User: arn:aws:sts::123456789012:assumed-role/my-lambda-func-role/myFunc is not authorized to perform: iam:PassRole on resource: arn:aws:iam::123456789012:role/ecsTaskExecutionRole
```
The solution ended up to be very simple. Switching to the JSON view in the Visual Editor showed that the generated JSON was pretty far away from what I was expecting it to be. Directly editing the JSON, and pasting in the following policies, resolved the issue immediately.
{% highlight json %}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ecs:RunTask"
],
"Resource": [
"*"
]
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
]
}
]
}
{% endhighlight %}