Skip to main content

AWS: Securing Internal APIs : A Deep Dive into REST API Security with AWS API Gateway and Microservices Integration Challenges

REST API Security | AWS API Gateway | Microservices


Problem Statement
We built a web application and some APIs for core functionalities of the application hosted in AWS Public Cloud. This is an internal application, and the API endpoints should be private, whereas the APIs are resolved outside the Enterprise network with the default endpoint generated in API Gateway. Hence, there is a need for a solution to set the API private.

Impact Analysis
The Web application is hosted in S3 as static hosting. The S3 bucket is set to private with the VPC-Endpoint policy as per the Client’s infrastructure standards. As per the current design, the application connects via an API Gateway and an internal ALB to the Java Microservices hosted in ECS containers in a private VPC.

Current Integration Flow: Web client → React App (S3) → API Gateway → Internal ALB → ECS (Java Services).

The current design uses AWS API Gateway with HTTP integration, which is public. Hence, we thought simply switching the integration type from HTTP to REST in the API Gateway can turn the APIs private. Yes, but the Private REST API methods cannot integrate with a private ALB directly, it only supports VPC Links to connect an NLB, not for ALB. This is an AWS design limitation. AWS support confirmed the same. In addition, the application is currently hosted in non-prod environments, so simply changing from public to private API will put the QA and UAT app sites down. Now, we need to make the APIs private and need to find a solution for ALB integration at the same time.

Design Limitations/Considerations
  • REST API only supports VPC Links to connect an NLB, not for ALB
  • API Gateway maintains HTTP integration between API Gateway to ALB, hence SSL is not required
  • ALB does not support default internet connectivity like API Gateway i.e. call to any external services like Okta (IAM)
  • S3 (VPCE) does not support HTTPS. That's why we are using the client’s HA-proxy-cluster (connects HTTPS to HTTP) between R53 and S3-app.
  • Client’s infra does not support Private DNS which is disabled with the VPC endpoint by default
  • S3 can integrate with the ALB but the application (hosted in S3) requests an HTTPS (security requirement) based API endpoints only
  • AWS API Gateway does not support Custom domain creation
Solution Options
There are two viable solutions overviewed on this post to overcome the API privacy issue (as stated above) for an internal application.

Option 1: Include an NLB to enable integration between API Gateway and the ALB.

Web client → React App (S3) → (Private) REST API (with VPCE Policy) → VPC link → Internal NLB (Layer 4) → Internal ALB (Layer 7) → Backend with ECS Microservices

Technical Approach
  • Create an NLB
  • Configure the API methods pointing to the NLB route
  • Configure the NLB routes pointing to the existing ALB route
  • No changes are required in existing ALB configurations
Option 2: Include a custom DNS and integrate with ALB endpoints without API Gateway.

Web client → React App (S3) → Custom DNS (R53) → Internal ALB (Layer 7) → Backend with ECS microservices

Technical Approach
  • Create an HTTPS listener in the ALB
  • Create a DNS (custom domain) with an SSL certificate via R53
  • Configure the DNS endpoints (sampleappapi.dev.abc.com) of ALB routes in the Web application
  • No changes are required in existing ALB configurations
Option 1:

PROS:
  • Using API Gateway is a standard pattern for a single-page-application to connect with ECS services
  • For better API development and management: allows defining headers, and methods of the Java Microservices
  • Inbuilt features like JWT Authorizer, CORS support and default HTTPS support can be leveraged
CONS:
  • NLB - additional resource cost added
  • API hosted in the AWS domain
  • Custom DNS is not supported so the API endpoint does have an auto generated URL
  • Custom DNS (A Record) managed e.g. api.dev.abc.com
  • Manual configuration with SSL certificate for the HTTPS domain
Option 2:

PROS:
  • Straightforward approach - direct connectivity between S3 (static app and ALB routes)
CONS:
  • Custom DNS (A Record) managed e.g. api.dev.abc.com
  • Manual configuration with SSL certificate for the HTTPS domain
Conclusion:
Option-1 is a common approach for building APIs with inbuilt features in the AWS ecosystem. Option-2 is a simple option for an internal application with manual configurations. Both options require minor changes in the CFT (IaC) scripts and end-to-end testing post-implementation. Both are recommended options by AWS support from an infra design and integration perspective to secure the API for an internal application. Therefore, the final decision is depending on what application demands either API Gateway's out box of features or simple integration!

Happy Solutioning!!
Labels:

Comments

Post a Comment

Popular posts from this blog

Fix: "Cannot set a credential for principal 'sa' . (Microsoft SQL Server, Error: 15535)" and “User is not associated with a trusted sql server connection" Errors

Recently, I had happen to struck with the following errors when I tried to reset the SA password through the SQL Server 2008 R2 Express. " Cannot set a credential for principal 'sa' . (Microsoft SQL Server, Error: 15535) " and then, “ User is not associated with a trusted sql server connection " From my research I have found the solution and that perfectly worked in SQL management studio. Hence, I thought of sharing my findings with others. ========================================================= Advertisement: Choosing .NET Core Worker Services OR Windows Services? ========================================================= Steps to reset the password in SQL Server 2008 R2 Express and fix for the errors: Step 1. Go to SQL Server Instance -> Properties/Security tab and change the mode to SQL Server authentication mode. Step 2. Go to Security/Logins, then open 'sa' login properties,          a. Uncheck the "Enforce passwor...
59 comments
Read more

How to Set Up SonarQube in IntelliJ: A Step-by-Step Guide

SonarQube in IntelliJ: (Looking for SonarLint then check here:  How to install and execute Sonarlint ) Setting up SonarQube in IntelliJ can significantly enhance your code quality by identifying bugs and vulnerabilities. Follow these steps to integrate SonarQube with IntelliJ: Step 1 :  Install SonarLint PluginOpen IntelliJ and navigate to Settings. Go to Plugins > Marketplace. Search for SonarLint, install it, and restart the IDE. Step 2 : Configure SonarLint Click on SonarLint at the bottom left of IntelliJ. Select Configure SonarLint. In the popup, check the box for Bind project to SonarQube/SonarCloud and click on Configure the connection. Step 3 :  Set Up the ConnectionIn the new popup, click the + icon to add a new connection. If the + icon is not visible, go to File > Settings > New UI and disable it. Apply changes and restart the IDE. Name your connection and select SonarQube. Enter the SonarQube URL (e.g., https://sonar.prod.company.com) and click Next....
Post a Comment
Read more

How to implement JUnit 5 in Your Maven or Gradle Project: A Step-by-Step Guide for Java Testing

Unit Testing JUnit Learn how to integrate JUnit 5 in your Maven or Gradle project for efficient Java testing. This guide covers adding dependencies, creating test classes, writing test methods, and running tests in IntelliJ IDEA and Visual Studio Code to ensure robust and error-free code. Step 1: Create a Simple Java Application Create a simple Java application, for example, “Copilot Demo,” and select Maven or Gradle as the build system through IntelliJ IDEA or Visual Studio Code. Step 2: Add JUnit Dependency For Maven: Add the following dependency to your pom.xml file inside the <dependencies> tag: XML <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-engine</artifactId> <version>5.11.2</version> <scope>test</scope> </dependency> For Gradle: Add the following dependencies to your build.gradle file: dependencies { testImplementation 'org.junit.jupiter:junit-jupiter-engine:5.11.2' } Step ...
Post a Comment
Read more