Share

How to setup IAM Permissions restricting a team to a particular API Gateway

Do you have several teams creating and maintaining different API Gateways? Do you need to restrict each team to its own API Gateway? This article is for you!

High-level Process

This article outlines a process for restricting a team to modifying a single API Gateway object. It assumes you will use an IAM Group for the team and that you will allow the team to view but not modify other APIs. If your situation is a little different you should be able to adapt the policies here to suit your needs.

To use this process, an admin account must create the API and an IAM Policy that allows access to it. The IAM Policy is then assigned to the Group or Users that make up the team.

Detailed Process

Create the API for the team

An admin user will need to create the API Gateway for the team and the find it ARN identifier so they can create a Policy to access the API.

  1. Login to the AWS Console as the Admin user.
  2. Navigate to the API Gateway Service. Click Get Started or Create API.
  3. Name the new API "foobar-api" and click Create API.

Find the ARN of the API

Next you need to locate the ARN identifier of the new API. You can find it in the URL when you are viewing the API in the Console. Look for the URL to appear like this:

https://console.aws.amazon.com/apigateway/home?region=REGION#/apis/API_ID/resources/API_RESOURCE_ID

Find the API identifier between "apis" and "resources" and copy it to your clipboard or somewhere else to use later when creaating the policy for the team's access.

An alternative way of finding the API is to use the AWS command-line interface:

1
2
3
4
5
6
7
8
9
10
% aws apigateway get-rest-apis --region us-east-1
{
"items": [
{
"createdDate": 1449667357,
"id": "API_ID",
"name": "foobar-api"
}
]
}

Setting up the team policy

  1. Navigate to the IAM Service and the Policies section.
  2. Click Create Policy and select Create your Own Policy.
  3. Set the Policy Name to "foobar-api-policy" and the Policy Document to the following. Replace "API_ID" with the actual id for your foobar API.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"apigateway:GET"
],
"Resource": [
"arn:aws:apigateway:*::/clientcertificates",
"arn:aws:apigateway:*::/restapis",
"arn:aws:apigateway:*::/restapis/*"
]
},
{
"Effect": "Allow",
"Action": [
"apigateway:*"
],
"Resource": [
"arn:aws:apigateway:us-east-1::/restapis/API_ID",
"arn:aws:apigateway:us-east-1::/restapis/API_ID/*"
]
}
]
}

Assign the Policy to the team

  1. Navigate to the IAM Service Groups or Users sections and locate the users and groups you want to have access to the API.
  2. Select the user or group and navigate to the Permissions tab and click Attach Policy.
  3. Type "foobar-api-policy" in the search field and click the check next to it.
  4. Click Attach Policy.
  5. Have one of the users log out then back in and confirm they can add a resource to the API.

Policy Statement Details

There are two parts to the policy statement: the first allows read-only access to all APIs, the second allows read/write access to the specific API. This lets the team see and copy APIs that have been generated by other teams but prevents them from changing them. The team can only change the API they are responsible for.

Granting read-only access to all APIs

Here is the first part of the statement that grants read-only access to all APIs:

1
2
3
4
5
6
7
8
"Action": [
"apigateway:GET"
],
"Resource": [
"arn:aws:apigateway:*::/restapis",
"arn:aws:apigateway:*::/restapis/*",
"arn:aws:apigateway:*::/clientcertificates"
]

  • Line 2: specifies read access is allowed.
  • Line 5: grants the ability to list all available APIs in any region.
  • Line 6: provides access to details of APIs such as resources and methods.
  • Line 7: called on the main API Gateway screen that lists all APIs. Discovered through trial and error.

Granting read/write access to the team's specific API

Here is the second part of the statement granting read/write access to the API owned by the team:

1
2
3
4
5
6
7
"Action": [
"apigateway:*"
],
"Resource": [
"arn:aws:apigateway:us-east-1::/restapis/API_ID",
"arn:aws:apigateway:us-east-1::/restapis/API_ID/*"
]

  • Line 2: assigns all operations to this privilege (GET, PUT, POST, DELETE).
  • Line 5: covers reading and writing top-level information about the api.
  • Line 6: adds subordinate information like resources and methods.

Other policy options

Here are a few suggestions of tweaks you might want to make to the policy described in this article.

Restrict team from seeing all APIs.

You might not want teams to be able to view the APIs of other teams. In this case you would want to remove the GET permission for for the root restapis resource. You could also restrict a team to viewing APIs in a particular region. You could also make separate read and write policies per API for very fine-grained control.

Restrict team from deleting the API.

You might want to avoid a team member accidentally deleting the API because that will mean you have to re-create it for them and re-assign the policy. To do this you would grant GET,POST, and PUT but not DELETE. That part of the statement would look something like this:

1
2
3
4
5
6
7
8
9
"Action": [
"apigateway:GET",
"apigateway:POST",
"apigateway:PUT"
],
"Resource": [
"arn:aws:apigateway:us-east-1::/restapis/API_ID",
"arn:aws:apigateway:us-east-1::/restapis/API_ID/*"
]

Add Lambda or other Service permissions.

The policy in this article will enable the team to change their API but if they need to connect it to other AWS services you may need to grant them other policies or modify your team-level one.

Interested in more?

Sign up for my mailing list. You'll get each new article and other announcements delivered to your inbox. I promise not to spam you. Unsubscribe any time you like.

Read the next article in your inbox!

* indicates required