Làm thế nào để thực thi Cloud Function một cách an toàn từ Google kubernetes engine đang chạy trên dự án GCP khác

Thu HaTr

1.png
Trong môi trường phức tạp có nhiều nhóm chạy Google Cloud projects khác nhau, rất khó đảm bảo một service trong project chỉ có thể truy cập bởi applications cụ thể. VPC peering và internal load balancing schemes trở nên phức tạp và các project không thể giao tiếp nếu không công khai services trên public Internet của nhiều vùng

Có một thử thách thú vị là công khai internal API như Cloud Function và muốn đảm bảo chỉ có application được ủy quyền chạy trên GCP projects của các nhóm lân cận mới có thể gọi chức năng này. Ngoài ra còn cần có một giải pháp mà application code của clients bị thay đổi ít nhất.

Nhóm không chỉ mong muốn về khả năng chạy internal API này trong serverless environment, mà mục tiêu lớn nhất là tránh việc thiết lập internal load balancing phức tạp và giảm tải tất cả xác thực service cho Google. Theo cách này sẽ không cần quản lý các quy tắc firewall phức tạp, thông báo với clients khi quy tắc thay đổi, quản lý giải pháp nhận dạng và chịu rủi ro về quản lý thông tin đăng nhập giữa các nhóm khác nhau.

Hoàn toàn có thể gọi Cloud Function bằng service account từ GCP project khác. Khi được kết hợp với các công nghệ như Workload Identity trên GKE, Cloud Function sẽ được gọi bởi một application cụ thể chạy trong bất kỳ GKE cluster nào trong bất kỳ project và tự quản lý tất cả mà không cần quản lý keys và thay đổi nhiều từ phía client.

Gọi Cloud Functions trong project đang chạy nhiều thành phần khác là vấn đề được xác định rõ ràng và được ghi lại, tuy nhiên có rất ít thông tin về cách sắp xếp nhiều projects, theo kiểu sẵn sàng sản xuất.

Hướng dẫn này sẽ tạo Cloud Function riêng trong GCP project. Sau đó, sẽ ủy quyền cho một service account từ GCP project khác và xem cách gọi Function (Hàm) bằng service account này. Tìm hiểu cách lập trình và cuối cùng là ghép các phần lại với nhau để có được thiết lập xác thực được quản lý hoàn toàn.

Chuẩn bị

Cần 2 Google Cloud projects để hoàn thành quy trình này. Một projects sẽ được gọi là Host Project và cái còn lại là Client Project. Đó là nơi sẽ tạo project và nơi chứa application và service account của nó.

Sẽ cần vai trò Cloud Functions Admin (cloudfunctions.admin) trong Host Project để đặt chính sách IAM của hàm. Cần vai trò Service Account Admin (iam.serviceAccountAdmin) và Service Account User (iam.serviceAccountUser) để tạo service accounts và keys trong Client Project.

Tạo Hàm

Điều hướng đến Host project và tạo Cloud Function mới trên GCP console. Chọn HTTP làm trình kích hoạt. Không chọn Allow unauthenticated invocations để chỉ cho phép gọi với GCP access token hợp lệ. Nếu không thể bỏ chọn, nghĩa là account không được phân quyền Cloud Functions Admin.
Sau vài giây, url sẽ được cung cấp để truy cập hàm này trên console. URL này có định dạng sau:
2.png
Chạy
3.png

để đảm bảo không được phép gọi hàm.

Tạo service account trong project khác

Sử dụng lệnh sau để tạo service account trong client project:
4.png
Tạo JSON key cho service account:
5.png

Chạy hàm với service account credentials

Kích hoạt service account cho gcloud:
6.png
Bây giờ, lệnh gcloud đang hoạt động như service account. Token để gọi hàm được lấy thông qua lệnh sau:
7.png
Hãy chắc chắn nhận được token sau khi chạy lệnh.
Bây giờ, hãy thêm token này vào yêu cầu và thử gọi hàm:
8.png
Yêu cầu này sẽ thất bại vì Cloud Function vẫn chưa được định cấu hình để chấp nhận yêu cầu từ service account này.

Cấp quyền cho Hàm

Cloud Functions Admin có thể đặt chính sách IAM cho từng Cloud Function. Bây giờ có thể gán quyền roles/cloudfunctions.invoker cho service account từ client project thông qua lệnh sau:
9.png
Xin lưu ý rằng cần phải thêm tham số — account vì trong bước trước, service account đã được dùng để dịnh danh một tài khoản. Tuy nhiên, service account không có quyền đặt chính sách IAM trên Cloud Function, vì vậy buộc phải đóng vai trò là user account.
Sau vài phút, khi quyền được giải quyết, hãy chạy lại lệnh curl với token truy cập:
10.png
Sẽ thấy output của Cloud Function.

Lập trình gọi Hàm bằng token (on-premise)

Đối với applications chạy trên môi trường on-premise, có thể phân bổ service account key cùng application và sử dụng Google’s auth library để tạo token. Dưới đây là ví dụ trong Node.js:

Vui lòng lưu ý ở đây đối tượng và URL được gọi có quyền giống nhau khi tìm nạp access token thông qua service account key.
Đọc Tài liệu Google Cloud IAP để xem thêm ví dụ trong các ngôn ngữ lập trình khác.

Lập trình gọi hàm từ GKE workloads bằng Workload Identity

Nếu application đang hoạt động trên GKE (hoặc GCE với compute metadata), có thể lấy access token trực tiếp từ metadata API. Trường hợp này không cần dùng đến Google’s Auth libraries nhưng có thể nhận được access token thông qua HTTP đơn giản và thêm nó vào yêu cầu vào Cloud Function.

Khi application chạy trên GKE, có thể dùng Workload Identity để quyết định Kubernetes Pod nào được dùng (thực ra là Kubernetes Service Account nào đang chạy cùng Pod) để đảm nhận vai trò GCP.
Vì tài liệu này đã đủ chi tiết, nên việc giải thích cách thiết lập Workload Identity cho Pod được bỏ qua. Khi hoàn tất thiết lập và chạy Pod bằng GCP service account được tạo trước đó, URL sau sẽ trả access key từ bên trong Pod:

11.png

Application có thể truy cập vào URL và tìm nạp access token, sau đó thêm token này vào yêu cầu Cloud Function để xác thực chính nó.
Xin lưu ý rằng phương pháp này không sử dụng service account key đã tạo trước đó. Nên xóa tất cả service account keys đã tạo vì mục đích của thiết lập này không phải quản lý thông tin đăng nhập.
Vui lòng xem Google’s document để biết thêm ví dụ chi tiết.

Tổng kết

Nếu là chủ sở hữu service hiển thị API dưới dạng Cloud Function, thì có thể yêu cầu clients tạo GCP service accounts và gán chúng cho GKE workload sẽ truy cập hàm. Khi biết GCP service account e-mail nào mà application này sẽ dùng, có thể tiếp tục và thêm e-mail này vào chính sách function’s IAM. Theo cách này, sẽ không phải quản lý (thậm chí tạo) keys, bảo mật và xoay vòng. Cần đảm bảo rằng hàm chỉ có thể được gọi bởi service account này và client có thể di chuyển account để cho phép nhiều applications truy cập vào hàm. Không cần phải giao tiếp để quản lý IP blocks, sắp xếp credentials và làm mọi công việc nhàm chán để chuẩn bị sẵn sàng sản xuất, thay vào đó, tất cả thời gian này hãy tập trung vào doanh nghiệp. Ngoài ra, chỉ cần đến một cuộc gọi HTTP là có thể điều chỉnh client application.

Nguồn: Medium
 
Top