Cloud SQL Auth Proxy so với đường VPN trực tiếp tới cơ sở dữ liệu
Auth Proxy và đường VPN trực tiếp giải quyết hai nửa khác nhau của cùng một vấn đề. Hãy so sánh trước quyền của connector, các cổng và đăng nhập cơ sở dữ liệu.
Có hai cách hợp lý để tới một instance Cloud SQL riêng tư từ laptop đang ở trên VPN. Một là kết nối trực tiếp tới địa chỉ riêng của instance qua tuyến đường bạn đã có. Cách còn lại là Cloud SQL Auth Proxy, vốn lắng nghe trên loopback và tự mở kết nối tới Cloud SQL. Chúng không hẳn là hai sản phẩm cạnh tranh mà là hai câu trả lời khác nhau cho câu hỏi ai giữ thông tin xác thực và ai giữ tuyến đường. Chọn sai thường hiện ra như một lỗi phân quyền mà đọc lên lại giống lỗi mạng.
Đây là bảng so sánh tôi sẽ đặt trước một đội, tiếp theo là những kiểm tra thực sự quyết định.
Hai con đường tới cùng một instance
Đường trực tiếp dùng tuyến private-services-access từ mạng của bạn vào VPC của dự án. Client của bạn nói PostgreSQL với địa chỉ riêng của instance, và kết nối sống hay chết dựa trên định tuyến, các quy tắc firewall và thông tin xác thực của cơ sở dữ liệu.
Đường qua proxy dùng cùng tuyến đó nhưng thêm một tiến trình cục bộ. Proxy xác thực với Google API bằng default credentials của ứng dụng, mở kết nối tới instance qua connector và mở một cổng loopback mà client của bạn coi là PostgreSQL. Hai chặng thành ba, và chặng giữa mang quyền IAM. Tuyến VPN vẫn là của bạn để duy trì, và proxy không bao giờ coi đó là thứ thay thế cho bước kiểm tra ấy.
Mỗi đường thực sự phân quyền điều gì
Khác biệt quan trọng nhất là mỗi lựa chọn có thể phân quyền gì thay bạn:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
Bước kiểm tra IAM của proxy và việc đăng nhập cơ sở dữ liệu là hai cổng riêng biệt, và qua được cổng này không mở cổng kia. Một đội bật proxy rồi cho rằng tài khoản ứng dụng không còn cần thiết sẽ mất cả buổi chiều với những lỗi mật khẩu không liên quan gì tới mạng.
Cổng và tuyến, đặt cạnh nhau
Proxy cần TCP 443 ra ngoài cho API và TCP 3307 cho kết nối tới instance, cả hai được mô tả trong tổng quan về Auth Proxy của Google. Tuyến VPN của bạn phủ cái thứ hai; cái thứ nhất thường đi ra theo đường thông thường.
Kết nối trực tiếp đòi hỏi cổng PostgreSQL của instance phải tới được qua tuyến riêng, đây là một cuộc trao đổi firewall hoàn toàn khác. Nếu đội mạng của bạn chỉ cho phép 443 ra ngoài từ các subnet client, proxy vừa khít mà không cần đổi quy tắc còn đường trực tiếp thì không. Chỉ một sự thật đó quyết định lựa chọn thường xuyên hơn mọi sở thích kiến trúc.
Không đường nào yêu cầu instance phải có địa chỉ công cộng, và không đường nào biện minh cho việc thêm một địa chỉ như vậy.
Nơi proxy không giúp được
Proxy không sửa được tuyến bị thiếu. Nếu tuyến private-services-access không có, hoặc VPN không mang nó, connector thất bại trong khi trình lắng nghe cục bộ vẫn ngồi đó lắng nghe, và đó chính là phần gây bối rối.
Nó cũng không bảo vệ đoạn giữa ứng dụng của bạn và proxy. Trên một laptop, đoạn đó là loopback và không sao. Nếu bạn gắn trình lắng nghe vào một địa chỉ wildcard để đồng nghiệp tới được, bạn đã dựng một cổng vào cơ sở dữ liệu không có xác thực và gọi đó là sự tiện lợi. Hãy giữ nó trên loopback và để đồng nghiệp tự lấy thông tin xác thực của mình.
Và nó không làm cho Private Service Connect và private services access thay thế được cho nhau. Một instance PSC cần cách bố trí DNS riêng và lời gọi --psc thay cho dạng --private-ip.
Chọn, rồi kiểm chứng dù theo cách nào
Chọn proxy khi bạn muốn IAM trên đường đi, thông tin xác thực ngắn hạn và không thay đổi firewall vào.
Chọn đường trực tiếp khi một client được hỗ trợ đã có thông tin xác thực cơ sở dữ liệu mạnh và đội mạng sẵn lòng mở cổng. Dù thế nào, hãy kiểm chứng bằng một truy vấn thật thay vì một kết nối thành công: kết nối, chạy một lần đọc trên bảng đã biết và xem máy chủ thấy gì về phiên của bạn.
Sau khi kết nối lại VPN, hãy coi thông tin xác thực hết hạn, tuyến riêng bị thiếu và việc bị từ chối đăng nhập cơ sở dữ liệu là ba sự cố khác nhau. Chỉ một trong số đó là vấn đề mạng, và chỉ một là thứ đáng dẫn tới việc sửa quy tắc firewall.