nathanpeck · June 11, 2025 23:42 · Jun 11, 2025
diff --git a/secure-containerized-mcp-servers-with-aws-creds.md b/secure-containerized-mcp-servers-with-aws-creds.md
@@ -0,0 +1,82 @@
+## Launch ECS Local Container Endpoints
+
+See [`awslabs/amazon-ecs-local-container-endpoints`](https://github.com/awslabs/amazon-ecs-local-container-endpoints/tree/mainline).
+
+This is an official container that mimics the Amazon ECS credential vending endpoint that is available in
+production AWS Fargate environments, and Amazon EC2 instances under Amazon ECS management. The credential vending
+endpoint is what allows an application running in AWS Fargate, under Amazon ECS management, to assume a given
+task IAM role.
+
+The following command utilizes `podman` but will also work with `docker`.
+
+```sh
+#!/bin/bash
+
+# Create the credentials network with a specific subnet
+podman network create credentials_network \
+  --subnet="169.254.171.0/24" \
+  --gateway="169.254.171.1"
+
+# Run the ECS local container endpoints with the specific IP address
+podman run -d \
+  --name ecs-local-endpoints \
+  --network credentials_network \
+  --ip 169.254.171.2 \
+  -v "$HOME/.aws/:/home/.aws/" \
+  -e AWS_PROFILE="default" \
+  amazon/amazon-ecs-local-container-endpoints
+```
+
+## Launch your MCP server in a container in the same network
+
+Rather than running the MCP server directly on host, we run it in an container
+linked to the same network. 
+
+We also pass two important environment variables that are baked into the AWS SDK,
+and therefore usable by any AWS SDK based application:
+
+* `ECS_CONTAINER_METADATA_URI` - Must match the defined IP address of the credential vending container
+* `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` - Two potential values for this variable
+   * `/creds` - Containerized application will get the same level of access that you have on your host
+   * `/task-arn/<task-arn>` - The credential vending container will use your host level credentials to assume this role
+     and the container will be given credentials for this role.
+
+Example config for the [AWS DynamoDB MCP Server](https://awslabs.github.io/mcp/#amazon-dynamodb-mcp-server):
+
+```json
+{
+  "mcpServers": {
+    "aws-dynamodb": {
+      "command": "podman",
+      "args": [
+        "run",
+        "--rm",
+        "--interactive",
+        "--network",
+        "credentials_network",
+        "--env",
+        "FASTMCP_LOG_LEVEL=ERROR",
+        "--env",
+        "AWS_CONTAINER_CREDENTIALS_RELATIVE_URI=/creds",
+        "--env",
+        "ECS_CONTAINER_METADATA_URI=http://169.254.171.2/v3",
+        "awslabs/dynamodb-mcp-server:latest"
+      ]
+    }
+  }
+}
+```
+
+## Important caveats
+
+There is nothing stopping a particularly malicious container from ignoring your configured `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`
+and choosing to fetch `/creds` to get your host level AWS credentials. Therefore if you are running untrustworthy MCP
+servers you should still use best practices by limiting how much scope you give the `amazon-ecs-local-container-endpoints`,
+so that it can't give your MCP servers too much access either.
+
+See:
+
+- `amazon-ecs-local-container-endpoints` on how to use a specific AWS profile: https://github.com/awslabs/amazon-ecs-local-container-endpoints/blob/mainline/docs/configuration.md#credentials
+- AWS documentation on how to configure multiple profiles, with separate access level for each profile: https://docs.aws.amazon.com/cli/v1/userguide/cli-configure-files.html
+
+