Cloud SQL Auth Proxy와 데이터베이스로 향하는 직접 VPN 경로
Auth Proxy와 직접 VPN 경로는 같은 문제의 서로 다른 절반을 해결합니다. 먼저 커넥터 권한 부여, 포트, 데이터베이스 로그인을 비교하세요.
VPN에 연결된 노트북에서 프라이빗 Cloud SQL 인스턴스에 도달하는 방법은 두 가지가 합리적입니다. 하나는 이미 가지고 있는 경로를 통해 인스턴스의 프라이빗 주소로 직접 연결하는 것입니다. 다른 하나는 loopback에서 수신하고 Cloud SQL로의 연결을 스스로 여는 Cloud SQL Auth Proxy입니다. 이 둘은 경쟁 제품이라기보다 자격 증명을 누가 들고 있고 경로를 누가 들고 있는가라는 질문에 대한 두 가지 다른 답입니다. 잘못 고르면 대개 네트워크 오류처럼 읽히는 권한 부여 오류로 드러납니다.
여기에 팀 앞에 놓을 비교를 적고, 이어서 실제로 판단을 가르는 확인 항목을 적습니다.
같은 인스턴스로 가는 두 경로
직접 경로는 네트워크에서 프로젝트 VPC로 들어가는 private-services-access 경로를 사용합니다. 클라이언트는 인스턴스의 프라이빗 주소와 PostgreSQL로 대화하고, 연결은 라우팅, firewall 규칙, 데이터베이스 자격 증명 위에서 살거나 죽습니다.
proxy 경로는 같은 경로를 쓰되 로컬 프로세스를 하나 더합니다. proxy는 애플리케이션의 default credentials로 Google API에 인증하고, 커넥터를 통해 인스턴스로 연결을 열며, 클라이언트가 PostgreSQL로 취급하는 loopback 포트를 제공합니다. 두 번의 홉이 세 번이 되고, 가운데 홉이 IAM 권한 부여를 담당합니다. VPN 경로는 여전히 직접 관리해야 하며, proxy는 그것을 이 확인의 대체물로 결코 보지 않습니다.
각 경로가 실제로 권한을 부여하는 것
가장 중요한 차이는 각 선택지가 대신 무엇을 권한 부여할 수 있는가입니다.
| 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 |
proxy의 IAM 확인과 데이터베이스 로그인은 별개의 관문이며, 하나를 통과해도 다른 하나가 열리지 않습니다. proxy를 켜고 애플리케이션 계정이 이제 필요 없다고 가정한 팀은 네트워크와 아무 관계 없는 비밀번호 실패에 반나절을 쓰게 됩니다.
포트와 경로를 나란히
proxy에는 API용 아웃바운드 TCP 443과 인스턴스 연결용 TCP 3307이 필요하며, 둘 다 Google의 Auth Proxy 개요 에 설명되어 있습니다. VPN 경로는 두 번째를 담당하고, 첫 번째는 보통 일반 경로로 나갑니다.
직접 연결은 인스턴스의 PostgreSQL 포트가 프라이빗 경로를 통해 도달 가능해야 하며, 이것은 전혀 다른 firewall 논의입니다. 네트워크 팀이 클라이언트 서브넷에서 아웃바운드 443만 허용한다면 proxy는 규칙 변경 없이 들어맞고 직접 경로는 그렇지 않습니다. 이 한 가지 사실이 어떤 아키텍처 선호보다도 자주 선택을 결정합니다.
어느 경로도 인스턴스에 공인 주소가 있어야 한다고 요구하지 않으며, 어느 쪽도 그것을 추가할 이유가 되지 않습니다.
proxy가 도움이 되지 않는 곳
proxy는 빠진 경로를 고치지 않습니다. private-services-access 경로가 없거나 VPN이 그것을 나르지 않으면, 로컬 리스너는 여전히 그 자리에 앉아 수신하는데 커넥터는 실패합니다. 혼란스러운 부분이 바로 이것입니다.
애플리케이션과 proxy 사이 구간도 보호하지 않습니다. 노트북 한 대에서는 그 구간이 loopback이라 문제없습니다. 동료가 닿을 수 있게 리스너를 wildcard 주소에 묶으면, 인증 없는 데이터베이스 게이트웨이를 만들고 그것을 편의라고 부른 셈입니다. loopback에 두고 동료가 자기 자격 증명을 얻도록 하세요.
또한 Private Service Connect와 private services access를 서로 바꿔 쓸 수 있게 만들지 않습니다. PSC 인스턴스에는 자체 DNS 구성과 --private-ip 형식 대신 --psc 호출이 필요합니다.
고르고, 어느 쪽이든 검증하기
경로에 IAM을 두고 싶고, 단기 자격 증명을 쓰고, 인바운드 firewall을 바꾸고 싶지 않다면 proxy를 고르세요.
지원되는 클라이언트가 이미 강한 데이터베이스 자격 증명을 가지고 있고 네트워크 팀이 포트를 열어도 된다면 직접 경로를 고르세요. 어느 쪽이든 성공한 연결이 아니라 실제 쿼리로 검증하세요. 연결하고, 알려진 테이블에 읽기를 하나 실행하고, 서버가 당신의 세션을 어떻게 보는지 확인하세요.
VPN 재연결 후에는 만료된 자격 증명, 빠진 프라이빗 경로, 데이터베이스 로그인 거부를 세 가지 다른 장애로 다루세요. 그중 네트워크 문제는 하나뿐이며, firewall 규칙 변경으로 이어져야 하는 것도 하나뿐입니다.