What is AWS API Gateway?
This fully managed service helps developers easily publish, monitor, secure, and maintain APIs at scale. You can go to the AWS Management Console to create an API that enables applications to access business logic and data.
Amazon API Gateway also lets you provide access to back-end functionality, including applications running on Elastic Container Service (Amazon ECS), Elastic Compute Cloud (EC2), and Elastic Beanstalk, and code that runs on AWS Lambda.
You can let Amazon API Gateway handle all tasks that involve processing and accepting hundreds of thousands of parallel API calls, such as traffic management, authorization, access control, API version management, and monitoring.
Options for controlling access to REST, HTTP, and WebSocket APIs
API Gateway provides various mechanisms that let you control and manage access to APIs. The following table summarizes which access control options are available for each type of API. Below we provide more details about each access control option.
|Access control option||REST||HTTP||WebSocket|
|API Gateway resource policies||✓|
|VPC endpoint policies for private APIs||✓|
|Using tags to control access to API Gateway resources||✓||✓|
|API Gateway Lambda authorizers||✓||✓||✓|
|Amazon Cognito user pools with authorizer permissions||✓|
6 ways to control access to APIs in AWS API Gateway
Amazon API Gateway lets you use various mechanisms to control and manage access to APIs. Here are the mechanisms you can use for authentication and authorization:
1. API Gateway resource policies
API Gateway resource policies consist of JSON documents you can attach to your API. Use these policies to control which principal can invoke a certain API. You can specify users from an AWS account, source IP address range, classless inter-domain routing (CIDR) blocks, virtual private cloud (VPC), or other endpoints. You can apply resource policies for every API endpoint type in API Gateway, including private, regional, and edge-optimized.
Note that Gateway resource policies work differently from IAM identity-based policies. You can attack IA policies to IAM roles, groups, or users and define the actions these identities can do on certain resources. You can attach API Gateway resource policies only to resources. You can, however, use the two policy types together.
2. IAM permissions
You use IAM permissions to restrict access to an Amazon API Gateway API by granting access to the following API Gateway components:
This component enables you to grant developers permission to perform actions that enable developers to create, deploy, and manage an API in API Gateway. It requires creating IAM permissions policies that allow a certain API developer to view, create, update, deploy, or delete a given API entity. Next, attach a policy to the IAM user, IAM group containing the user, or an IAM role associated with this user.
This component enables you to grant an API caller permission to perform IAM actions like calling a deployed API or refreshing the API caching. You must first create IAM policies to allow a certain API caller to invoke the desired API method enabled for the IAM user authentication.
3. Use VPC endpoint policies for private APIs in API Gateway
You can configure API Gateway to use an interface VPC endpoint to secure your private APIs. AWS PrivateLink supports interface endpoints, letting you use a private IP address to privately access AWS services.
A VPC endpoint policy consists of an IAM resource policy attached to an interface VPC endpoint, controlling access to this endpoint. Use endpoint policies to restrict the traffic flowing from an internal network to private APIs. It lets you allow or deny access to certain private APIs to which the VPC endpoint provides access.
You can use VPC endpoint policies with API Gateway resource policies – your resource policy specifies the principals that can access the API, and the endpoint policy defines the private APIs that can be called through the VPC endpoint.
4. Using tags to control access to API Gateway resources
AWS IAM policies use conditions as part of the syntax that lets you specify permissions to various API Gateway resources. In API Gateway, resources and certain actions can include tags. Adding tag condition keys to IAM policies enables you to control the following aspects:
- Define specific users allowed to perform actions on a certain API Gateway resource according to the resource’s tags.
- Specify the tags that can be passed in an action’s request.
- Determine whether a certain tag key can be used in a request.
You can leverage tags for attribute-based access control (ABAC). It enables you to achieve more granular control than API-level control and more dynamic control than resource-based access control (RBAC).
You can create IAM policies that allow or deny an operation according to request tags (when creating new resources) or resource tags (for existing resources).
5. API Gateway Lambda authorizers
The Lambda authorizer feature employs a Lambda function to control access to an API. You can use it to implement a custom authorization scheme that uses request parameters to determine a caller’s identity or a bearer token authentication strategy like SAML or OAuth. Once a client makes a request to an API method, API Gateway calls the Lambda authorizer, which takes the caller’s identity and returns the relevant IAM policy.
6. Amazon Cognito user pools with authorizer permissions
An Amazon Cognito user pool can help you control who can access an API. It requires creating an authorizer for the COGNITO_USER_POOLS component and configuring an API method to use the authorizer. Once the API is deployed, the client must:
- Sign the user into the user pool.
- Obtain an identity or access token for the user.
- Call the API method using the token, usually set to the request’s authorization header.
The API call can succeed only if the required token is available and found valid. Otherwise, the client cannot be authorized to make this call.
AWS API Gateway authentication with Gloo Gateway
Many companies choose to use Solo.io Gloo Gateway in place of AWS API-Gateway due to the ability to:
- Reduce costs due to AWS API-GW charging based on the number of API calls plus cache memory vs. Solo API-Gateway charging based on the number of clusters.
- Deploy Solo API-Gateway in AWS or non-AWS environments
- Integrate Solo API-Gateway more tightly with Kubernetes environments, both in AWS and outside AWS.