Cloud SQL Auth Proxy กับการเดิน VPN ตรงไปยังฐานข้อมูล
Auth Proxy และการเดิน VPN ตรงแก้ปัญหาคนละครึ่งของปัญหาเดียวกัน เริ่มจากเทียบการอนุญาตของคอนเนกเตอร์ พอร์ต และการเข้าสู่ระบบฐานข้อมูล
มีสองวิธีที่สมเหตุสมผลในการเข้าถึงอินสแตนซ์ Cloud SQL แบบส่วนตัวจากแล็ปท็อปที่ต่อ VPN วิธีหนึ่งคือเชื่อมต่อตรงไปยังที่อยู่ส่วนตัวของอินสแตนซ์ผ่านเส้นทางที่คุณมีอยู่แล้ว อีกวิธีคือ Cloud SQL Auth Proxy ซึ่งฟังบน loopback และเปิดการเชื่อมต่อไปยัง Cloud SQL เอง ทั้งสองไม่ใช่ผลิตภัณฑ์ที่แข่งขันกันมากนัก แต่เป็นสองคำตอบที่ต่างกันสำหรับคำถามว่าใครถือข้อมูลรับรองและใครถือเส้นทาง การเลือกผิดมักปรากฏเป็นข้อผิดพลาดด้านการอนุญาตที่อ่านแล้วเหมือนข้อผิดพลาดของเครือข่าย
นี่คือการเปรียบเทียบที่ผมจะวางไว้หน้าทีม ตามด้วยการตรวจสอบที่ตัดสินจริง ๆ
สองเส้นทางสู่อินสแตนซ์เดียวกัน
เส้นทางตรงใช้เส้นทาง private-services-access จากเครือข่ายของคุณเข้าไปใน VPC ของโปรเจกต์ ไคลเอนต์ของคุณพูด PostgreSQL กับที่อยู่ส่วนตัวของอินสแตนซ์ และการเชื่อมต่อจะอยู่หรือตายบนการกำหนดเส้นทาง กฎ firewall และข้อมูลรับรองของฐานข้อมูล
เส้นทางผ่านพร็อกซีใช้เส้นทางเดียวกันแต่เพิ่มโพรเซสในเครื่อง พร็อกซีพิสูจน์ตัวตนกับ Google API ด้วย default credentials ของแอปพลิเคชัน เปิดการเชื่อมต่อไปยังอินสแตนซ์ผ่านคอนเนกเตอร์ และเปิดพอร์ต loopback ที่ไคลเอนต์ของคุณถือว่าเป็น PostgreSQL การกระโดดสองครั้งกลายเป็นสาม และตัวกลางเป็นผู้ถือการอนุญาต IAM เส้นทาง VPN ยังคงเป็นของคุณในการดูแล และพร็อกซีไม่เคยถือว่าเป็นตัวแทนของการตรวจสอบนั้น
แต่ละเส้นทางอนุญาตอะไรจริง ๆ
ความแตกต่างที่สำคัญที่สุดคือแต่ละตัวเลือกอนุญาตอะไรแทนคุณได้:
| 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 |
การตรวจสอบ IAM ของพร็อกซีและการเข้าสู่ระบบฐานข้อมูลเป็นสองประตูแยกกัน และการผ่านประตูหนึ่งไม่ได้เปิดอีกประตู ทีมที่เปิดพร็อกซีแล้วถือว่าบัญชีแอปพลิเคชันไม่จำเป็นอีกต่อไปจะเสียเวลาค่อนวันกับความล้มเหลวของรหัสผ่านที่ไม่เกี่ยวข้องกับเครือข่ายเลย
พอร์ตและเส้นทาง เทียบกัน
พร็อกซีต้องใช้ TCP 443 ขาออกสำหรับ API และ TCP 3307 สำหรับการเชื่อมต่ออินสแตนซ์ ทั้งสองอธิบายไว้ใน ภาพรวม Auth Proxy ของ Google เส้นทาง VPN ของคุณครอบคลุมตัวที่สอง ส่วนตัวแรกปกติออกผ่านเส้นทางปกติ
การเชื่อมต่อตรงต้องให้พอร์ต PostgreSQL ของอินสแตนซ์เข้าถึงได้ผ่านเส้นทางส่วนตัว ซึ่งเป็นการคุยเรื่อง firewall ที่ต่างไปเลย ถ้าทีมเครือข่ายของคุณอนุญาตเฉพาะ 443 ขาออกจากซับเน็ตของไคลเอนต์ พร็อกซีก็เข้ากันได้โดยไม่ต้องแก้กฎ ส่วนเส้นทางตรงไม่ได้ ข้อเท็จจริงข้อเดียวนี้ตัดสินการเลือกบ่อยกว่าความชอบด้านสถาปัตยกรรมใด ๆ
ทั้งสองเส้นทางไม่ต้องการให้อินสแตนซ์มีที่อยู่สาธารณะ และไม่มีเส้นทางใดสมเหตุสมผลที่จะเพิ่มเข้าไป
ที่ที่พร็อกซีไม่ช่วย
พร็อกซีไม่ได้แก้เส้นทางที่หายไป. ถ้าเส้นทาง private-services-access ไม่มี หรือ VPN ไม่ได้พามันไป คอนเนกเตอร์จะล้มเหลวในขณะที่ตัวฟังในเครื่องยังนั่งฟังอยู่ตรงนั้น และนั่นคือส่วนที่ทำให้สับสน
มันยังไม่ปกป้องช่วงระหว่างแอปพลิเคชันของคุณกับพร็อกซี บนแล็ปท็อปเครื่องเดียวช่วงนั้นเป็น loopback และเรียบร้อย ถ้าคุณผูกตัวฟังกับที่อยู่ wildcard เพื่อให้เพื่อนร่วมงานเข้าถึงได้ คุณได้สร้างเกตเวย์ฐานข้อมูลที่ไม่มีการพิสูจน์ตัวตนและเรียกว่าความสะดวก เก็บมันไว้บน loopback และปล่อยให้เพื่อนร่วมงานขอข้อมูลรับรองของตัวเอง
และมันไม่ได้ทำให้ Private Service Connect กับ private services access ใช้แทนกันได้ อินสแตนซ์ PSC ต้องมีการจัด DNS ของตัวเองและการเรียก --psc แทนรูปแบบ --private-ip
เลือก แล้วตรวจสอบไม่ว่าจะทางไหน
เลือกพร็อกซีเมื่อคุณต้องการ IAM ในเส้นทาง ข้อมูลรับรองอายุสั้น และไม่มีการแก้ firewall ขาเข้า
เลือกเส้นทางตรงเมื่อไคลเอนต์ที่รองรับมีข้อมูลรับรองฐานข้อมูลที่แข็งแรงอยู่แล้ว และทีมเครือข่ายพร้อมเปิดพอร์ต ไม่ว่าจะทางไหน ให้ตรวจสอบด้วยคำสั่งค้นหาจริงไม่ใช่การเชื่อมต่อที่สำเร็จ: เชื่อมต่อ รันการอ่านหนึ่งครั้งบนตารางที่รู้จัก และดูว่าเซิร์ฟเวอร์เห็นอะไรเกี่ยวกับเซสชันของคุณ
หลังจากเชื่อมต่อ VPN ใหม่ ให้ถือว่าข้อมูลรับรองที่หมดอายุ เส้นทางส่วนตัวที่หายไป และการปฏิเสธการเข้าสู่ระบบฐานข้อมูลเป็นความล้มเหลวสามอย่างที่ต่างกัน มีเพียงหนึ่งเดียวที่เป็นปัญหาเครือข่าย และมีเพียงหนึ่งเดียวที่ควรนำไปสู่การแก้กฎ firewall