Cloud SQL Auth Proxy ile veritabanına doğrudan VPN rotası
Auth Proxy ve doğrudan VPN rotası aynı sorunun farklı yarılarını çözer. Önce bağlayıcı yetkilendirmesini, portları ve veritabanı oturum açmasını karşılaştırın.
VPN'deki bir dizüstü bilgisayardan özel bir Cloud SQL örneğine ulaşmanın iki makul yolu var. Biri, zaten sahip olduğunuz rota üzerinden örneğin özel adresine doğrudan bağlantı. Diğeri, loopback üzerinde dinleyen ve Cloud SQL'e bağlantıyı kendisi açan Cloud SQL Auth Proxy. Bunlar rakip ürünlerden çok, kimlik bilgisini kimin tuttuğu ve rotayı kimin tuttuğu sorusuna iki farklı yanıttır. Yanlış seçim genellikle ağ hatası gibi okunan bir yetkilendirme hatası olarak ortaya çıkar.
İşte bir ekibin önüne koyacağım karşılaştırma ve ardından bunu gerçekten belirleyen kontroller.
Aynı örneğe iki yol
Doğrudan yol, ağınızdan projenin VPC'sine giden private-services-access rotasını kullanır. İstemciniz örneğin özel adresiyle PostgreSQL konuşur ve bağlantı yönlendirme, firewall kuralları ve veritabanı kimlik bilgileri üzerinde yaşar ya da ölür.
Proxy yolu aynı rotayı kullanır ama yerel bir süreç ekler. Proxy, uygulamanızın default credentials değerleriyle Google API'ye kimlik doğrular, bağlayıcı üzerinden örneğe bir bağlantı açar ve istemcinizin PostgreSQL olarak gördüğü bir loopback portu sunar. İki atlama üçe çıkar ve ortadaki IAM yetkilendirmesini taşır. VPN rotası yine sizin bakımınızda kalır ve proxy bunu asla o denetimin yerine geçen bir şey olarak görmez.
Her yol gerçekte neyi yetkilendirir
En önemli fark, her seçeneğin sizin adınıza neyi yetkilendirebileceğidir:
| 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'nin IAM denetimi ile veritabanı oturum açması iki ayrı kapıdır ve birinden geçmek diğerini açmaz. Proxy'yi açıp uygulama hesabının artık gereksiz olduğunu varsayan bir ekip, ağla hiç ilgisi olmayan parola hatalarına bir öğleden sonra harcar.
Portlar ve rotalar yan yana
Proxy, API için giden TCP 443 ve örnek bağlantısı için TCP 3307 gerektirir; ikisi de Google'ın Auth Proxy genel bakışında açıklanmıştır. VPN rotanız ikincisini kapsar; birincisi genellikle olağan yoldan çıkar.
Doğrudan bağlantı, örneğin PostgreSQL portunun özel rota üzerinden erişilebilir olmasını gerektirir ki bu tamamen başka bir firewall konuşmasıdır. Ağ ekibiniz istemci alt ağlarından yalnızca giden 443'e izin veriyorsa proxy herhangi bir kural değişikliği olmadan uyar, doğrudan yol uymaz. Bu tek gerçek, seçimi herhangi bir mimari tercihten daha sık belirler.
İki yoldan hiçbiri örneğin genel bir adresi olmasını gerektirmez ve hiçbiri böyle bir adres eklemeyi haklı çıkarmaz.
Proxy'nin yardımcı olmadığı yer
Proxy eksik bir rotayı onarmaz. private-services-access rotası yoksa veya VPN onu taşımıyorsa bağlayıcı başarısız olur, yerel dinleyici ise hâlâ orada oturup dinlemektedir ve kafa karıştıran kısım budur.
Uygulamanız ile proxy arasındaki bölümü de korumaz. Tek bir dizüstünde bu bölüm loopback'tir ve sorun yoktur. Bir iş arkadaşının erişebilmesi için dinleyiciyi wildcard bir adrese bağlarsanız, kimlik doğrulaması olmayan bir veritabanı geçidi kurmuş ve buna kolaylık demiş olursunuz. Onu loopback üzerinde tutun ve iş arkadaşınız kendi kimlik bilgisini alsın.
Ayrıca Private Service Connect ile private services access'i birbirinin yerine kullanılabilir hale getirmez. Bir PSC örneği kendi DNS düzenine ve --private-ip biçimi yerine --psc çağrısına ihtiyaç duyar.
Seçmek ve sonra her durumda doğrulamak
Yolda IAM, kısa ömürlü kimlik bilgileri ve gelen firewall'da değişiklik istemiyorsanız proxy'yi seçin.
Desteklenen bir istemci zaten güçlü veritabanı kimlik bilgilerine sahipse ve ağ ekibi portu açmaya istekliyse doğrudan rotayı seçin. Her durumda başarılı bir bağlantı yerine gerçek bir sorguyla doğrulayın: bağlanın, bilinen bir tabloda bir okuma çalıştırın ve sunucunun oturumunuz hakkında ne gördüğünü kontrol edin.
VPN yeniden bağlandıktan sonra süresi dolmuş kimlik bilgisini, eksik özel rotayı ve veritabanı oturum açmasının reddedilmesini üç farklı arıza olarak değerlendirin. Bunlardan yalnızca biri ağ sorunudur ve yalnızca biri bir firewall kuralının değiştirilmesine yol açmalıdır.