My Awesome Project

Appearance

Consumer vs Producer — IAM & Approval Workflow ​

Tại Sao Phần Này Quyết Định Production ​

Sự cố PSC phổ biến nhất trong vận hành là một câu duy nhất: "endpoint của tôi mãi ở trạng thái PENDING". Đằng sau triệu chứng đó là một cơ chế kiểm soát truy cập hai phía mà nếu không hiểu, bạn sẽ debug mù. Producer có toàn quyền quyết định ai được kết nối, qua một bộ máy gồm connection preference, accept/reject list, và connection limit. Consumer chỉ "yêu cầu" kết nối; việc nó thành công hay không nằm ở phía producer.

File này mổ xẻ bộ máy đó đến tận cơ chế trạng thái, để bạn biết chính xác vì sao một connection được accept hay bị giữ PENDING — và sửa đúng chỗ. Đây cũng là tầng bảo mật cốt lõi của mô hình multi-tenant: nó là nơi "explicit authorization" của PSC được thực thi.

Internal Model: Hai Phía, Hai Loại Quyết Định ​

Mỗi PSC connection là kết quả của hai quyết định độc lập:

  1. Consumer quyết định tạo endpoint trỏ tới một service attachment URI. Đây là hành động "đề nghị kết nối". Consumer cần biết URI của service attachment (do producer cung cấp).

  2. Producer quyết định có chấp nhận connection đó không, dựa trên cấu hình của service attachment. Đây mới là quyết định cuối cùng quyết định traffic có chảy được không.

Sự bất đối xứng này phản ánh đúng triết lý PSC: producer là người sở hữu service và kiểm soát truy cập; consumer chỉ là bên xin. Hiểu điều này giúp bạn biết khi PENDING thì chìa khóa nằm ở producer, không phải consumer.

Connection Preference: ACCEPT_AUTOMATIC vs ACCEPT_MANUAL ​

Producer cấu hình service attachment với một trong hai connection preference (About controlling access to published services):

ACCEPT_AUTOMATIC ​

Service attachment tự động chấp nhận mọi inbound connection từ bất kỳ consumer nào. Bất kỳ ai biết URI service attachment và có quyền tạo endpoint đều kết nối được ngay, không cần producer phê duyệt.

Đây là mô hình phù hợp cho service công khai trong nội bộ tin cậy — ví dụ một internal API mà toàn tổ chức được dùng, và bạn kiểm soát ai biết URI bằng cách khác (IAM trên project). Không phù hợp cho multi-tenant với consumer không tin cậy.

ACCEPT_MANUAL ​

Service attachment chỉ chấp nhận connection nếu consumer nằm trong consumer accept list. Mọi consumer khác sẽ ở trạng thái PENDING cho tới khi được thêm vào list. Đây là mô hình mặc định nên dùng cho mọi service expose ra ngoài tổ chức hoặc multi-tenant.

Mental model: ACCEPT_AUTOMATIC là "default allow"; ACCEPT_MANUAL là "default deny + allowlist". Với bất kỳ service nào mà tập consumer không hoàn toàn tin cậy, ACCEPT_MANUAL là lựa chọn an toàn duy nhất.

Accept List & Reject List ​

Cấu trúc và giới hạn ​

Với ACCEPT_MANUAL, producer quản lý hai danh sách (About controlling access to published services):

  • Consumer accept list — ai được phép kết nối. Tối đa 5.000 giá trị.
  • Consumer reject list — ai bị chặn rõ ràng. Tối đa 64 giá trị.

Mỗi giá trị có thể định danh consumer theo:

  • Project (consumer project ID hoặc number),
  • VPC network, hoặc
  • Private Service Connect endpoint (URI cụ thể của một endpoint).

Granularity này quan trọng: bạn có thể cho phép cả một project, hay chỉ một endpoint cụ thể trong project đó. Reject list được đánh giá để chặn rõ ràng — hữu ích khi bạn muốn allow một project nhưng chặn một endpoint cá biệt trong đó.

Approval theo endpoint URI ​

Một workflow thực tế quan trọng: producer publish service ở chế độ explicit approval; consumer tạo endpoint (nó hiện PENDING); consumer gửi URI của endpoint cho producer; producer thêm URI đó vào accept list để thiết lập connection (About controlling access to published services). Đây là mô hình "consumer xin, producer duyệt từng cái" — phù hợp khi producer muốn kiểm soát chặt từng endpoint, không chỉ từng project.

Connection Limit: Cơ Chế Tinh Tế Nhất ​

Vấn đề mà connection limit giải quyết ​

Một consumer project có thể tạo nhiều endpoint trỏ tới cùng một service attachment. Nếu không kiểm soát, một consumer có thể vô tình (hoặc cố ý) tạo hàng trăm endpoint, làm cạn NAT subnet của producer (mỗi connection tốn 1 NAT IP — xem file 01) và ảnh hưởng các consumer khác.

Connection limit giải quyết điều này: với mỗi project/network trong accept list, producer cấu hình giới hạn số connection mà consumer đó được tạo (About controlling access to published services).

Cơ chế trạng thái khi vượt limit ​

Đây là điểm gây nhầm lẫn nhất, nên cần chính xác. Khi một consumer vượt connection limit của họ:

  • Các connection trong giới hạn được ACCEPTED.
  • Connection vượt giới hạn ở trạng thái PENDING — cho tới khi limit được tăng, hoặc consumer xóa bớt connection (About controlling access to published services).

Tài liệu nêu ví dụ rõ: "connection từ project-2 được accept, và connection từ project-3 vẫn PENDING" cho tới khi limit tăng hoặc consumer được thêm vào accept list.

Hệ quả debug quan trọng: PENDING có hai nguyên nhân khác nhau — (1) consumer chưa nằm trong accept list, hoặc (2) consumer đã trong accept list nhưng đã vượt connection limit. Hai nguyên nhân này cần hai cách xử lý khác nhau (thêm vào list vs tăng limit). Không phân biệt được → sửa sai chỗ. Đây là nhánh đầu tiên trong cây quyết định troubleshoot ở file 07.

Các Connection State Liên Quan Đến Approval ​

Approval workflow xoay quanh ba state chính (tập đầy đủ 5 state ở file 07):

  • PENDING — connection chưa thiết lập; traffic không chảy được. Xảy ra khi cần approval (chưa trong accept list) hoặc vượt limit (About controlling access to published services).
  • ACCEPTED — producer đã chấp nhận và cấu hình cho phép; traffic chảy được.
  • REJECTED — bị chặn bởi org policy hoặc reject list.

Một chi tiết cơ chế đáng nhớ: ở trạng thái PENDING, endpoint đã tồn tại trong VPC consumer (đã tốn IP, đã hiện trong console) nhưng traffic không đi được. Đây là lý do "ping không thông" dù endpoint đã tạo — endpoint tồn tại không có nghĩa là connection đã ACCEPTED.

IAM: Ai Cần Quyền Gì Ở Hai Phía ​

Approval workflow được bảo vệ bởi IAM ở cả hai phía. Các quyền cốt lõi:

Phía consumer (tạo endpoint) ​

  • Quyền tạo forwarding rule / address trong VPC — thường qua role như roles/compute.networkAdmin trên consumer project (Cloud SQL cũng yêu cầu compute.networkAdmin để tạo endpoint — Cloud SQL with PSC).
  • Với managed service, cần quyền trên service tương ứng để khai báo allowed projects / auto-connect.

Phía producer (publish & approve) ​

  • Quyền tạo và quản lý service attachment (roles/compute.networkAdmin trên producer project).
  • Quyền sửa accept/reject list để approve/deny connection.

Org Policy như một tầng kiểm soát trên cùng ​

Trên cả IAM, Organization Policy có thể chặn việc tạo PSC endpoint hoàn toàn, qua constraints/compute.disablePrivateServiceConnectCreationForConsumers. Nếu policy này active, ngay cả khi consumer có IAM đầy đủ, việc tạo endpoint vẫn fail. Đây là cơ chế để security team áp đặt "không ai trong org được tự ý tạo PSC endpoint ra ngoài" — một guardrail chống data exfiltration ở tầng tổ chức.

Mental model phân tầng kiểm soát: Org Policy (có được tạo endpoint không?) → IAM (user này có quyền tạo không?) → Connection preference + accept list + limit (producer có chấp nhận connection này không?). Một connection chỉ ACCEPTED khi vượt qua cả ba tầng.

Pattern: Multi-Tenant SaaS Producer ​

Một SaaS chạy trên GCP, bán dịch vụ private cho nhiều khách hàng doanh nghiệp, mỗi khách một GCP project. Đây là use case kinh điển của PSC producer.

Thiết kế dựa trên cơ chế:

  • Service attachment dùng ACCEPT_MANUAL — không bao giờ auto-accept với khách hàng bên ngoài.
  • Mỗi khách hàng được thêm vào accept list theo project, với connection limit phù hợp gói dịch vụ (ví dụ gói cơ bản 2 connection, gói enterprise 10).
  • NAT subnet được size theo tổng connection limit của tất cả khách (mỗi connection 1 IP) — nếu bán 1000 khách × 2 connection = 2000 IP, cần ít nhất /21.
  • Dùng PSC connection ID + PROXY protocol (file 01) để attribute traffic về đúng tenant cho billing/audit.

Bài học: accept list + connection limit không chỉ là bảo mật, chúng là công cụ quản lý capacity và tier dịch vụ. Connection limit ánh xạ trực tiếp vào gói bán hàng; NAT subnet size ánh xạ vào tổng capacity.

Anti-Pattern: Dùng ACCEPT_AUTOMATIC Cho Service Multi-Tenant ​

Vì sao sai về cơ chế: ACCEPT_AUTOMATIC nghĩa là bất kỳ ai biết URI service attachment đều kết nối được, không qua phê duyệt. URI không phải secret mạnh — nó có thể lộ qua log, config, hoặc bị đoán. Trong multi-tenant, điều này phá vỡ chính cái property bảo mật mà PSC sinh ra để bảo vệ: explicit authorization.

Hệ quả ở scale: một consumer ngoài ý muốn (hoặc độc hại) kết nối vào service, tiêu thụ NAT IP, và có thể chạm tới service mà không bị kiểm soát. Tệ hơn, vì không có accept list, bạn không có cách nào audit ai đang kết nối — mất khả năng attribute và thu hồi truy cập theo từng tenant.

Cách đúng: luôn dùng ACCEPT_MANUAL cho service expose ra ngoài tổ chức hoặc multi-tenant. ACCEPT_AUTOMATIC chỉ dành cho service nội bộ tin cậy nơi việc kiểm soát URI và IAM project đã đủ.

References ​