AWS Study Group

Triển khai custom domain name cho Amazon API Gateway private endpoints sử dụng reverse proxy

của James Beswick | ngày 05 tháng 6 năm 2023 | trong Amazon API Gateway, Serverless | Permalink |  Share

Bài viết này được viết bởi Heeki Park, Principal Solutions Architect, Sachin Doshi, Senior Application Architect, và Jason Enderle, Senior Solutions Architect.

Amazon API Gateway cho phép các lập trình viên tạo ra private REST APIs mà chỉ có thể truy cập từ bên trong một Virtual Private Cloud (VPC). Lưu lượng truy cập đến private API được truyền qua các kết nối an toàn và nằm trong mạng AWS và cụ thể là trong VPC của khách hàng, bảo vệ nó khỏi mạng Internet. Cách tiếp cận này có thể được sử dụng để giải quyết các yêu cầu về quy định hoặc bảo mật của khách hàng bằng cách đảm bảo tính bảo mật của lưu lượng truyền. Điều này làm private API Gateway endpoints phù hợp cho các API nội bộ, chẳng hạn như các API được sử dụng bởi các vi dịch vụ và API dữ liệu.

Trong kiến trúc microservice, các team thường xây dựng và quản lý các thành phần bên trong những tài khoản AWS riêng biệt và ưu tiên truy cập vào các private API endpoints này sử dụng custom domain name dành riêng cho công ty. Tùy chỉnh tên miền đóng vai trò là một bí danh cho hostname và path của API của bạn. Điều này làm cho client kết nối dễ dàng hơn bằng URL và cũng duy trì một URL ổn định trong trường hợp API endpoint URL thay đổi. Tùy chỉnh tên miền cũng có thể cải thiện việc tổ chức API theo chức năng của chúng trong doanh nghiệp. Ví dụ, định dạng API Gateway URL tiêu chuẩn là: “https://api-id.execute-api.region.amazonaws.com/stage” can be transformed into “https://api.private.example.com/myservice”.

Tổng quan

Bài đăng trên blog này được xây dựng dựa trên tài liệu bao gồm frontend gọi đến private endpoints và mô hình tích hợp backend cũng như hai bài viết đã được đăng trước đó.

Bài đăng đầu tiên giúp bạn sử dụng private API endpoints từ API Gateway, sử dụng một Lambda function hỗ trợ cho VPC và một ứng dụng container sử dụng mTLS. Bài đăng thứ hai giúp bạn thực thi private backend thích hợp với  API microservices của bạn được triển khai sử dụng AWS Fargate hoặc Amazon EC2. Bài viết này sẽ mở rộng những điều đó, cho phép bạn đơn giản việc truy cập vào API endpoints bằng cách triển khai cấu hình tên miền cho private endpoint sử dụng NGINX reverse proxy.

Giải pháp này sử dụng NGINX vì nó đóng vai trò như một chương trình trung gian có hiệu suất cao, cho phép chuyển tiếp lưu lượng truy cập một cách hiệu quả đến private network. Một file cấu hình mapping liên kết tên miền của bạn với private endpoints tương ứng trên tài khoản AWS. Cấu hình file mapping này có thể được kiểm soát nguồn và sử dụng để triển khai được quản lý vào môi trường sản xuất và cấp thấp hơn của bạn.

Sơ đồ sau minh họa sự tương tác giữa các thành phần và đường dẫn cho một API request. Trong trường hợp này, một tài khoản dịch vụ chia sẻ (Account A) chịu trách nhiệm quản lý tập trung những mapping của những custom domain name và tạo ra một AWS PrivateLink kết nối private API endpoints trong tài khoản nhà cung cấp (Account B và Account C).

  1. Một request đến API được thực hiện bằng cách sử dụng một private custom domain name bên trong một VPC hoặc một thiết bị khác có thể định tuyến đến VPC. Ví dụ, request có thể sử dụng tên miền https://api.private.example.com.
  2. Một alias record trong Amazon Route 53 private hosted zone giải quyết cho tên miền đủ điều kiện của private Elastic Load Balancing (ELB). ELB có thể được cấu hình là một Network Load Balancer (NLB) hoặc một Application Load Balancer (ALB).
  3. ELB sử dụng chứng chỉ AWS Certificate Manager (ACM) để chấm dứt TLS (Transport Layer Security) cho những private custom domain name tương ứng.
  4. ELB listener chuyển hướng các request đến một ELB target group được liên kết và lần lượt chuyển tiếp những request đến Amazon Elastic Container Service chạy task trên AWS Fargate.
  5. Dịch vụ Fargate tạo ra container dựa trên NGINX đóng vai trò như một reverse proxy cho private API endpoint trong một hoặc nhiều tài khoản được cung cấp. Dịch vụ Fargate được cấu hình để scale sử dụng số liệu theo dõi việc sử dụng CPU tự động.
  6. Fargate task, điều hướng lưu lượng truy cập đến những private endpoints phù hợp trong tài khoản nhà cung cấp B hoặc tài khoản C thông qua một PrivateLink VPC Endpoint.
  7. API Gateway resource policy giới hạn truy cập đến private endpoints dựa trên những VPC endpoint, HTTP verbs và source domain cụ thể được sử dụng để yêu cầu API.

Giải pháp truyền bất kỳ thông tin bổ sung nào được tìm thấy trong các header từ upstream calls, chẳng hạn như authentication headers, content type headers hoặc custom data headers không được sửa đổi cho các private endpoints trong tài khoản nhà cung cấp (tài khoản B và tài khoản C).

Điều kiện tiên quyết

Để sử dụng custom domain name, bạn cần hai thành phần là chứng chỉ TLS và DNS alias. Ví dụ này sử dụng ACM để quản lý chứng chỉ TLS và Route 53 để tạo ra DNS alias.

ACM cung cấp nhiều tùy chọn để tích hợp một chứng chỉ TLS, chẳng hạn như:

  1. Importing một chứng chỉ TLS đã tồn tại vào trong ACM.
  2. Yêu cầu một chứng chỉ TLS trong ACM với Email-based validation.
  3. Yêu cầu một chứng chỉ TLS trong ACM với DNS-based validation.
  4. Yêu cầu một chứng chỉ TLS từ ACM sử dụng Organization’s Private CA trong AWS.

Sơ đồ sau đây minh họa các lợi ích và nhược điểm liên quan đến từng tùy chọn.

Giải pháp này sử dụng DNS-based validation (tùy chọn 3) để yêu cầu một chứng chỉ TLS từ ACM. Giả định rằng một public hosted zone với một root domain đã được đăng ký (chẳng hạn như: example.com) đã được triển khai trong tài khoản mục tiêu. Sau đó, giải pháp này sử dụng ACM để  xác thực quyền sở hữu của tên miền được chỉ định trong cấu hình mapping file khi triển khai

Với một public hosted zone được triển khai, những tên miền con riêng (chẳng hạn như api.private.example.com) có thể được triển khai sử dụng DNS validation mà cho phép triển khai infrastructure as code (IaC) để tự động xác thực chứng chỉ trong khi triển khai giải pháp. Thêm vào đó, DNS-based validation tự động làm mới chứng chỉ ACM trước khi nó hết hạn.

Giải pháp này yêu cầu sự hiện diện của các VPC endpoints xác định, namely execute-api, logs, … và  Amazon S3 gateway trong tài khoản dịch vụ được chia sẻ (tài khoản A). Kích hoạt private DNS trên execute-api VPC endpoint là tùy chọn và không phải là một yêu cầu của giải pháp này. Một vài khách hàng có thể chọn không bật private DNS trên execute-api VPC endpoint, vì điều này sau đó cho phép các ứng dụng trong VPC có thể tiếp cận với private API endpoints thông qua NGINX reverse proxy nhưng cũng giải quyết các public API Gateway endpoint.

Triển khai ví dụ

Bạn có thể sử dụng AWS Cloud Development Kit (CDK) hoặc code Terraform có sẵn trên GitHub để triển khai ví dụ này trong tài khoản của bạn.

Giải pháp này sử dụng một mapping file cấu hình dựa trên YAML để thêm, cập nhật hoặc là xóa một mapping giữa một custom domain và private API endpoint. Trong khi triển khai, tập lệnh trong infrastructure as code (IaC) được cung cấp và thực hiện như sau: 

  • Tạo ra một cấu hình NGINX
  • Áp dụng tệp cấu hình NGINX vào trong NGINX container image tiêu chuẩn
  • Phân tích mapping file và tạo ra Route 53 private hosted zones cần thiết trong tài khoản A.
  • Tạo ra chứng chỉ wildcard-based SSL (chẳng hạn như *.example.com) trong tài khoản A. ACM sẽ xác thực những chứng chỉ này sử dụng public hosted zone tương ứng của nó (chẳng hạn như example.com) và gắn chúng vào ELB listener. Theo mặc định, một ELB listener hỗ trợ đến 25 chứng chỉ SSL. Wildcards được sử dụng để bảo mật một số lượng lớn các tên miền phụ, giúp quản lý và mở rộng quy mô nhiều tên miền phụ hơn.

Mô tả những field trong mapping file

Thuộc tínhBắt buộcGiá trị ví dụMô tả
CUSTOM_DOMAIN_URLtrueapi.private.example.comURL tùy chỉnh theo mong muốn cho những API riêng
PRIVATE_API_URLtruehttps://a1b2c3d4e5.execute-api.us-east-1.amazonaws.com/dev/path1/path2URL thực thi của targeted private endpoint
VERBSfalse[“GET”,” POST”, “PUT”, “PATCH”, “DELETE”, “HEAD”, “OPTIONS”]Thuộc tính này sẽ được sử dụng để tạo ra những API Gateway resource policy.
Bạn có thể cung cấp một hoặc nhiều verbs phân cách nhau bởi dấu phẩy. Nếu thuộc tính này không được cung cấp, tất cả các verb sẽ được cho phép 

Sử dụng API Gateway resource policies cho private endpoints

Để cho phép truy cập vào private endpoints từ những VPC của bạn hoặc từ các tài khoản khác, bạn phải triển khai một resource policy. Resource policies có thể được sử dụng để giới hạn truy cập dựa trên những tiêu chí cụ thể như VPC endpoints, API paths và API verbs. Để bật chức năng này, làm theo những bước sau:

  • Hoàn thành triển khai infrastructure as code (IaC)
  • Tạo hoặc cập nhật một API Gateway resource policy trong tài khoản nhà cung cấp (chẳng hạn như tài khoản B và tài khoản C). Policy này nên bao gồm VPC endpoint id từ tài khoản dịch vụ chia sẻ (tài khoản A).
  • Triển khai API của bạn để áp dụng những thay đổi trong tài khoản cung cấp (chẳng hạn như tài khoản B và tài khoản C).

Để cập nhật API Gateway resource policy với code, tham khảo các tài liệu và code ví dụ trong GitHub repo.

Triển khai các cập nhật cho mapping file

Để thêm, sửa, và xóa một mapping giữa custom domain của bạn và private endpoint, bạn có thể cập nhật mapping file và sau đó chạy lại việc triển khai bằng cách sử dụng các bước tương tự như trước.

Việc triển khai các bản cập nhật tiếp theo vào mapping file bằng infrastructure as code pipeline làm giảm nguy cơ lỗi của con người, thêm truy xuất nguồn gốc, ngăn chặn sự trôi dạt cấu hình và cho phép quá trình triển khai tuân theo các quy trình quản trị hiện tại của bạn.

Ví dụ, bạn có thể lưu trữ file cấu hình mapping trong source control repository riêng biệt và commit từng thay đổi cho repository đó. Mỗi thay đổi sau đó có thể kích hoạt một quy trình triển khai, sau đó sẽ kiểm tra các thay đổi cấu hình và tiến hành triển khai phù hợp. Nếu được yêu cầu, bạn có thể giới thiệu GATE để thực thi kiểm tra thủ công hoặc quy trình bán vé để đảm bảo rằng các quy trình kiểm soát thay đổi được thực thi.

Hiểu chi phí của giải pháp

Hầu hết các dịch vụ được đề cập trong giải pháp này được tính tiền theo mức sử dụng, được xác định bởi số lượng request được thực hiện.

Tuy nhiên, có một vài dịch vụ phải trả phí theo giờ hoặc theo tháng. Những chi phí hàng tháng cho Route 53 hosted zones, theo giờ cho VPC endpoints, Elastic Load Balancing và chi phí chạy NGINX reverse proxy, bạn có thể sử dụng  AWS pricing calculator. Dưới đây là một ví dụ phác thảo chi phí gần đúng liên quan đến kiến trúc được thực hiện trong giải pháp này.

Kết luận

Bài viết này cho thấy một giải pháp cho phép khách hàng sử dụng private endpoint của họ để tăng tính an toàn với API Gateway trên nhiều tài khoản AWS và bên trong một VPC network sử dụng một reverse proxy với một custom domain name. Giải pháp này đêm đến một cách tiếp cận đơn giản để quản lý những mapping giữa private endpoints với API Gateway và những custom domain name, đảm bảo kết nối liền mạch và an toàn.

Để có thêm tài nguyên học tập không có máy chủ, hãy truy cập Serverless Land.

Link bài viết

←
→

Leave a comment