Amazon API Gateway example: Only IAM users from another account

Published: August 2, 2024

Amazon API Gateway Example: Only IAM Users from Another Account

Source: AWS

Imagine in a project you are using Amazon API Gateway to define REST APIs. You, as a developer want to allow only IAM users from another AWS account to access the APIs. What would you do?

Create an IAM Permission Policy

Create an IAM policy in the other AWS account (the account where the IAM users are located) that grants the necessary permissions to invoke the API Gateway methods.

The policy should look something like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:{region}:{account-id}:{api-id}/*"
    }
  ]
}

Attach the Policy to the IAM Users or Groups

Attach the created IAM policy to the IAM users or groups in the other AWS account who need access to the API.

Set the Method Authorization Type for the APIs to AWS_IAM:

In the AWS account where the API Gateway is deployed, set the authorization type for the API methods to AWS_IAM. This can be done via the API Gateway console, AWS CLI, or AWS SDKs.

4.1. Create a Resource Policy for the APIs to Allow Access for All IAM Users from the Other AWS Account

Create a resource policy for the API Gateway to allow access for all IAM users from the other AWS account. This policy is attached directly to the API Gateway. An example resource policy might look like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{other-account-id}:root"
      },
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:{region}:{account-id}:{api-id}/*"
    }
  ]
}

The Principal field specifies the IAM user or role that is allowed to invoke the API. In here "root" means all IAM users in the other account.

4.2. Create a Resource Policy for the APIs to Allow Access for Each IAM User Only Alternatively, you can create a resource policy for the API Gateway to explicitly allow each IAM user from the other AWS account to access the APIs. This policy is attached directly to the API Gateway. An example resource policy might look like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{other-account-id}:user/{iam-username}"
      },
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:{region}:{account-id}:{api-id}/*"
    }
  ]
}

The Principal field specifies the IAM user or role that is allowed to invoke the API. In here, you can specify the IAM user's ARN to allow access only for that user, which is more granular.

Signature Version 4 Using Authorization Header

Source

Use Signature Version 4 to Sign the API Requests:

Ensure that the API requests are signed using AWS Signature Version 4. This involves using the AWS SDKs or manually signing the requests following the steps outlined in the AWS documentation.

If you are using the AWS SDKs, the SDK will handle the signing process for you. But if you are making requests manually, you should follow the steps mentioned in the Create a signed AWS API request user guide or the AWS Signature Version 4 for API requests.

Copyright & Disclaimer

All content provided on this article is for informational and educational purposes only. The author makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site.
All the content is copyrighted, except the assets and content I have referenced to other people's work, and may not be reproduced on other websites, blogs, or social media. You are not allowed to reproduce, summarize to create derivative work, or use any content from this website under your name. This includes creating a similar article or summary based on AI/GenAI. For educational purposes, you may refer to parts of the content, and only refer, but you must provide a link back to the original article on this website. This is allowed only if your content is less than 10% similar to the original article.
While every care has been taken to ensure the accuracy of the content of this website, I make no representation as to the accuracy, correctness, or fitness for any purpose of the site content, nor do I accept any liability for loss or damage (including consequential loss or damage), however, caused, which may be incurred by any person or organization from reliance on or use of information on this site.
The contents of this article should not be construed as legal advice.
Opinions are my own and not the views of my employer.
English is not my mother-tongue language, so even though I try my best to express myself correctly, there might be a chance of miscommunication.
Links or references to other websites, including the use of information from 3rd-parties, are provided for the benefit of people who use this website. I am not responsible for the accuracy of the content on the websites that I have put a link to and I do not endorse any of those organizations or their contents.
If you have any queries or if you believe any information on this article is inaccurate, or if you think any of the assets used in this article are in violation of copyright, please contact me and let me know.