Amazon API Gateway cho phép các nhà phát triển tạo ra các private REST API chỉ có thể được truy cập từ bên trong VPC. Lưu lượng truy cập tới các private API này được truyền tải thông qua các đường kết nối an toàn và nằm trong mạng AWS, đặc biệt là trong những VPC của khách hàng nhằm bảo vệ chúng khỏi 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 sẽ giúp cho các private API Gateway endpoint phù hợp để xuất bản các API nội bộ, chẳng hạn như các API được sử dụng bởi các microservices và các API dữ liệu.
Trong kiến trúc microservice, nhóm các nhà phát triển thường xây dựng và quản lý từng thành phần (components) trong các tài khoản AWS riêng biệt và ưu tiên việc truy cập vào các private API endpoint đó thông qua tên miền của công ty. Tên miền tùy chỉnh đóng vai trò là bí danh cho tên máy chủ và đường dẫn tới API của bạn. Điều này giúp khách hàng kết nối dễ dàng hơn sử dụng các URL dễ nhớ và duy trì URL ổn định trong trường hợp API endpoint của URL thay đổi. Tên miền tùy chỉnh sẽ cải thiện việc tổ chức lại cá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: “https://execute-api.us-east-1.amazonaws.com/stage” có thể được chuyển đổi thành “https://api.private.example.com/myservice”.
I. Tổng quan
Bài blog này được xây dựng dựa trên các tài liệu chứa Cách frontend gọi private endpoint và Các mẫu thiết kế tích hợp backend cũng như hai bài blog đã được đăng tải trước đó.
Bài blog đầu tiên giúp bạn xử lý các private API endpoint từ API Gateway thông qua Lambda function hỗ trợ VPC và ứng dụng container-based sử dụng mTLS. Bài đăng thứ hai trước đó giúp bạn thực hiện tích hợp private backend với microservice API triển khai trên AWS Fargate hoặc Amazon EC2. Bài đăng này là một phần mở rộng cho phép bạn đơn giản hóa quyền truy cập đến API endpoint của mình bằng cách triển khai tên miền tùy chỉnh cho private endpoint bằng NGINX reverse proxy.
Giải pháp này sử dụng NGINX vì nó hoạt động như một kênh trung gian có hiệu năng cao, cho phép chuyển tiếp lưu lượng truy cập trong mạng riêng một cách hiệu quả. Tệp ánh xạ cấu hình liên kết tên miền tùy chỉnh của bạn với private endpoint tương ứng trên các tài khoản AWS. Tệp ánh xạ cấu hình này có thể được áp dụng cơ chế kiểm soát mã nguồn và sử dụng để quản trị các triển khai đến môi trường production và các 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 của một API request. Trong trường hợp này, tài khoản dịch vụ dùng chung (Tài khoản A) chịu trách nhiệm quản lý tập trung các ánh xạ của tên miền tùy chỉnh và tạo kết nối thông qua AWS PrivateLink tới các private API endpoint của tài khoản được cung cấp (Tài khoản B và Tài khoản C).
- Một yêu cầu gửi đến API thông qua tên miền tùy chỉnh bên trong VPC hoặc thiết bị khác có thể định tuyến đến VPC. Ví dụ: Yêu cầu đó có thể sử dụng miền https://api.private.example.com.
- Bản ghi bí danh trong private hosted zone của Amazon Route 53 phân giải thành FQDN của private Elastic Load Balancing (ELB). ELB có thể là Network Load Balancer (NLB) hoặc Application Load Balancer (ALB).
- ELB sử dụng chứng chỉ cung cấp bởi AWS Certification Manager (ACM) để chấm dứt TLS (Transport Layer Security) cho miền riêng tùy chỉnh tương ứng.
- ELB listener điều hướng các yêu cầu đến ELB target group được liên kết, từ đó chuyển tiếp yêu cầu tới tác vụ Amazon Elastic Container Service chạy trên AWS Fargate.
- Dịch vụ Fargate hosts một NGINX container hoạt động như một reverse proxy cho private API endpoint trong một hoặc nhiều tài khoản nhà cung cấp. Fargate được định cấu hình để scale up tự động bằng cách sử dụng các thông số thu được thông qua giám sát mức sử dụng CPU.
- Tác vụ trên Fargate chuyển tiếp lưu lượng truy cập đến các private endpoint thích hợp trong Tài khoản B hoặc Tài khoản C của nhà cung cấp thông qua PrivateLink VPC Endpoint.
- Chính sách tài nguyên của API Gateway giới hạn quyền truy cập vào các private endpoint dựa trên VPC endpoint dựa trên HTTP methods và tên miền dùng gọi đến API.
Giải pháp này cũng sẽ chuyển mọi thông tin bổ sung tìm thấy trong header từ lệnh gọi ngược tuyến, chẳng hạn như authentication headers, content type headers hoặc tcustom data headers chưa được sửa đổi tới private endpoint trong tài khoản nhà cung cấp (Tài khoản B và Tài khoản C).
II. Yêu cầu tiên quyết
Để sử dụng tên miền tùy chỉnh, bạn cần có hai thành phần: chứng chỉ TLS và DNS alias. Ví dụ này sẽ sử dụng ACM để quản lý chứng chỉ TLS và Route 53 cho việc tạo DNS alias.
ACM cung cấp nhiều lựa chọn khác nhau để tích hợp chứng chỉ TLS, chẳng hạn như:
- Nhập chứng chỉ TLS hiện có vào ACM.
- Yêu cầu chứng chỉ TLS trong ACM với cơ chế xác thực thông qua Email.
- Yêu cầu chứng chỉ TLS trong ACM với cơ chế xác thực thông qua DNS.
- Yêu cầu chứng chỉ TLS từ ACM bằng CA riêng của tổ chức bạn trong AWS.
Sơ đồ sau đây minh họa những lợi ích và hạn chế tương ứng với từng lựa chọn.
Giải pháp này sử dụng xác thực dựa trên DNS (lựa chọn số 3) để yêu cầu chứng chỉ TLS từ ACM. Giả định rằng một public hosted zone với tên miền gốc đã được đăng ký (chẳng hạn như example.com) đã được triển khai trong tài khoản đích. Sau đó, giải pháp sử dụng ACM để xác thực quyền sở hữu tên miền được chỉ định trong tệp ánh xạ cấu hình trong quá trình triển khai.
Với một public hosted zone được triển khai, các tên miền con riêng tư (private child domain) (chẳng hạn như api.private.example.com) có thể được triển khai bằng cách sử dụng xác thực DNS, cho phép triển khai cơ sở hạ tầng dưới dạng mã (IaC) để tự động xác thực chứng chỉ trong quá trình triển khai giải pháp. Ngoài ra, xác thực dựa trên DNS sẽ tự động gia hạn chứng chỉ ACM trước khi hết hạn.
Giải pháp này yêu cầu sự có mặt của một số VPC endpoint cụ thể, cụ thể là exec-api, log, ecr.dkr, ecr.api và Amazon S3 gateway trong tài khoản dịch vụ dùng chung (Tài khoản A). Việc bật private DNS trên execute-api VPC endpoint là không bắt buộc và không phải là yêu cầu của giải pháp này. Một số khách hàng có thể chọn không bật private DNS trên exec-api VPC endpoint, vì điều này cho phép các ứng dụng trong VPC truy cập private API endpoint thông qua NGINX reverse proxy đồng thời cũng phân giả được các public API Gateway endpoints.
III. Triển khai một ví dụ mẫu
Bạn có thể sử dụng ví dụ mẫu về AWS Cloud Development Kit (CDK) hoặc Terraform code có sẵn trên GitHub để triển khai mẫu này trong tài khoản của cá nhân bạn.
Giải pháp này sử dụng tệp ánh xạ cấu hình YAML để thêm, cập nhật hoặc xóa ánh xạ giữa tên miền tùy chỉnh và private API endpoint. Trong quá trình triển khai, các script IaC tự động sẽ truyền vào tệp YAML được cung cấp và thực hiện những việc sau:
- Tạo tệp cấu hình cho NGINX
- Áp dụng cấu hình của NGINX cho NGINX container tiêu chuẩn.
- Truyền tệp ánh xạ và khởi tạo các Route 53 private hosted zones cần thiết trong Tài khoản A
- Tạo chứng chỉ SSL dựa theo tên miền phụ (wildcard) (chẳng hạn như *.example.com) trong Tài khoản A. ACM xác thực các chứng chỉ này dựa trên public hosted zone tương ứng (chẳng hạn như example.com) và gán các chứng chỉ đó vào ELB listener. Theo mặc định, ELB listener hỗ trợ tối đa 25 chứng chỉ SSL. Wildcards được sử dụng để bảo mật số lượng không giới hạn tên miền phụ, giúp quản lý và mở rộng quy mô nhiều tên miền phụ dễ dàng hơn.
Mô tả về các trường ánh xạ trong tệp
| Tên thuộc tính | Cần thiết | Giá trị mẫu | Mô tả |
| CUSTOM_DOMAIN_URL | Có | api.private.example.com | URL tùy chỉnh mong muốn cho private API. |
| PRIVATE_API_URL | Có | https://a1b2c3d4e5.execute-api.us-east-1.amazonaws.com/dev/path1/path2 | URL thực thi cho private endpoint mục tiêu |
| VERBS | Không | [“GET”,” POST”, “PUT”, “PATCH”, “DELETE”, “HEAD”, “OPTIONS”] | Thuộc tính này sẽ được sử dụng để tạo chính sách tài nguyên cho API Gateway. Bạn có thể cung cấp một hoặc nhiều verbs dưới dạng danh sách cách nhau bởi dấu phẩy. Nếu không cung cấp thuộc tính này, cho phép tất cả các verbs. |
IV. Sử dụng chính sách tài nguyên cho private API Gateway endpoint
Để cho phép truy cập vào các private endpoints từ VPC của bạn hoặc từ VPC trong tài khoản khác, bạn phải triển khai chính sách tài nguyên (resource policies). Chính sách tài nguyên có thể dùng để hạn chế quyền truy cập dựa theo một số tiêu chí cụ thể như VPC endpoint, đường dẫn trong API (path) và API verbs. Để sử dụng tính năng này, hãy làm theo các bước sau:
- Hoàn thiện việc triển khai cơ sở hạ tầng dưới dạng mã (IaC).
- Tạo hoặc cập nhật chính sách tài nguyên API Gateway 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). Chính sách này phải chứa id VPC endpoint của tài khoản dịch vụ dùng chung (Tài khoản A).
- Triển khai API của bạn để áp dụng các thay đổi 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).
Để cập nhật chính sách tài nguyên API Gateway bằng mã, hãy tham khảo tài liệu và code mẫu trong GitHub.
V. Triển khai các bản cập nhật cho tệp ánh xạ
Để thêm, cập nhật hoặc xóa ánh xạ giữa tên miền tùy chỉnh và private endpoint, bạn có thể cập nhật tệp ánh xạ rồi thực thi lại quá trình triển khai theo 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 cho tệp ánh xạ bằng cách sử dụng IaC pipelines giúp giảm nguy cơ xuất hiện lỗi do yếu tố con người, bổ sung khả năng truy vết, ngăn ngừa tình trạng “lệch 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ị và DevOps hiện tại của bạn.
Ví dụ: bạn có thể lưu trữ tệp ánh xạ cấu hình trong kho lưu trữ riêng biệt nhằm kiểm soát mã nguồn và commit từng thay đổi đối lên kho lưu trữ đó. Sau đó, mỗi thay đổi có thể sẽ kích hoạt quy trình triển khai, quy trình này sẽ kiểm tra các thay đổi về cấu hình và tiến hành quá trình triển khai sao cho phù hợp.
VI. Có cái nhìn về 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 đều được tính phí theo mức sử dụng, được xác định bởi số lượng yêu cầu (request) được thực hiện.
Tuy nhiên, có một số dịch vụ phát sinh chi phí hàng giờ hoặc hàng tháng. Chúng bao gồm phí hàng tháng cho các hosted zone trên Route 53, phí hàng giờ cho VPC endpoint, Cân bằng tải (ELB) và chi phí hàng giờ để chạy NGINX reverse proxy trên Fargate. Để ước tính chi phí cho các dịch vụ này dựa trên khối lượng công việc cụ thể của bạn, bạn có thể sử dụng công cụ tính chi phí của AWS. Đây là ví dụ phác thảo chi phí gần đúng liên quan đến kiến trúc được triển khai trong giải pháp này.
VII. Kết luận
Bài viết này đã trình bày giải pháp cho phép khách hàng sử dụng private endpoint của họ một cách an toàn với API Gateway trên nhiều tài khoản AWS và trong cùng VPC bằng cách sử dụng reverse proxy sở hữu tên miền tuỳ chỉnh. Giải pháp này đơn giản hóa cách tiếp cận để quản lý việc ánh xạ giữa các private endpoint với API Gateway và tên miền tùy chỉnh, đảm bảo kết nối bảo mật và liền mạch.
Để tìm thêm học liệu về chủ đề Serverless, hãy truy cập Serverless Land.
AWS Study Group 