Cloud SQL Auth Proxy versus rute VPN langsung ke database
Auth Proxy dan rute VPN langsung menyelesaikan dua bagian berbeda dari masalah yang sama. Bandingkan dulu otorisasi konektor, port, dan login database.
Ada dua cara masuk akal untuk mencapai instance Cloud SQL privat dari laptop di VPN. Yang satu koneksi langsung ke alamat privat instance lewat rute yang sudah Anda miliki. Yang lain Cloud SQL Auth Proxy, yang mendengarkan di loopback dan membuka sendiri koneksi ke Cloud SQL. Keduanya bukan produk bersaing, melainkan dua jawaban berbeda atas pertanyaan siapa memegang kredensial dan siapa memegang rute. Pilihan yang keliru biasanya muncul sebagai galat otorisasi yang terbaca seperti galat jaringan.
Berikut perbandingan yang akan saya ajukan ke sebuah tim, disusul pemeriksaan yang benar-benar menentukan.
Dua jalur ke instance yang sama
Jalur langsung memakai rute private-services-access dari jaringan Anda ke VPC proyek. Klien Anda berbicara PostgreSQL dengan alamat privat instance, dan koneksinya hidup atau mati pada perutean, aturan firewall, dan kredensial database.
Jalur proxy memakai rute yang sama tetapi menambah proses lokal. Proxy mengautentikasi ke Google API dengan default credentials aplikasi Anda, membuka koneksi ke instance lewat konektor, dan mengekspos port loopback yang diperlakukan klien Anda sebagai PostgreSQL. Dua lompatan menjadi tiga, dan yang di tengah membawa otorisasi IAM. Rute VPN tetap milik Anda untuk dirawat, dan proxy tidak pernah menganggapnya pengganti pemeriksaan itu.
Apa yang sebenarnya diotorisasi tiap jalur
Pembeda yang paling penting adalah apa yang bisa diotorisasi tiap opsi untuk Anda:
| 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 |
Pemeriksaan IAM proxy dan login database adalah dua gerbang terpisah, dan melewati satu tidak membuka yang lain. Tim yang mengaktifkan proxy lalu menganggap akun aplikasi tidak lagi diperlukan akan menghabiskan satu sore pada kegagalan kata sandi yang tidak ada hubungannya dengan jaringan.
Port dan rute, berdampingan
Proxy membutuhkan TCP 443 keluar untuk API dan TCP 3307 untuk koneksi instance, keduanya dijelaskan di ikhtisar Auth Proxy milik Google. Rute VPN Anda mencakup yang kedua; yang pertama biasanya keluar lewat jalur biasa.
Koneksi langsung membutuhkan port PostgreSQL instance dapat dijangkau lewat rute privat, yang merupakan pembicaraan firewall yang sama sekali lain. Jika tim jaringan Anda hanya mengizinkan 443 keluar dari subnet klien, proxy cocok tanpa perubahan aturan dan jalur langsung tidak. Satu fakta itu menentukan pilihan lebih sering daripada preferensi arsitektur mana pun.
Tidak satu pun jalur menuntut instance punya alamat publik, dan tidak ada yang membenarkan menambahkannya.
Di mana proxy tidak membantu
Proxy tidak memperbaiki rute yang hilang. Jika rute private-services-access tidak ada, atau VPN tidak membawanya, konektor gagal sementara pendengar lokal masih duduk di sana mendengarkan, dan itulah bagian yang membingungkan.
Proxy juga tidak melindungi ruas antara aplikasi Anda dan proxy. Di satu laptop ruas itu loopback dan baik-baik saja. Jika Anda mengikat pendengar ke alamat wildcard agar rekan bisa menjangkaunya, Anda telah membangun gateway database tanpa autentikasi dan menyebutnya kemudahan. Biarkan di loopback dan biarkan rekan memperoleh kredensialnya sendiri.
Dan proxy tidak membuat Private Service Connect dan private services access saling menggantikan. Instance PSC butuh penataan DNS sendiri dan pemanggilan --psc alih-alih bentuk --private-ip.
Memilih, lalu memverifikasi bagaimanapun caranya
Pilih proxy ketika Anda ingin IAM di jalur, kredensial berumur pendek, dan tanpa perubahan firewall masuk.
Pilih rute langsung ketika klien yang didukung sudah memegang kredensial database yang kuat dan tim jaringan nyaman membuka port. Bagaimanapun, verifikasi dengan kueri sungguhan alih-alih koneksi yang berhasil: sambungkan, jalankan satu pembacaan pada tabel yang dikenal, dan periksa apa yang dilihat server tentang sesi Anda.
Setelah VPN tersambung ulang, perlakukan kredensial kedaluwarsa, rute privat yang hilang, dan penolakan login database sebagai tiga kegagalan berbeda. Hanya satu yang merupakan masalah jaringan, dan hanya satu yang semestinya membuat Anda mengubah aturan firewall.