Cloud SQL Auth Proxy pret tiešu VPN maršrutu uz datubāzi
Auth Proxy un tiešs VPN maršruts risina dažādas vienas problēmas puses. Vispirms salīdziniet konektora autorizāciju, portus un pierakstīšanos datubāzē.
Ir divi saprātīgi veidi, kā no klēpjdatora VPN sasniegt privātu Cloud SQL instanci. Viens ir tiešs savienojums ar instances privāto adresi pa maršrutu, kas jums jau ir. Otrs ir Cloud SQL Auth Proxy, kas klausās uz loopback un pats atver savienojumu ar Cloud SQL. Tie ir ne tik daudz konkurējoši produkti, cik divas atšķirīgas atbildes uz jautājumu, kam pieder akreditācijas dati un kam pieder maršruts. Slikta izvēle parasti izpaužas kā autorizācijas kļūda, kas tiek lasīta kā tīkla kļūda.
Lūk, salīdzinājums, ko es liktu komandas priekšā, un pēc tam pārbaudes, kas to patiešām izšķir.
Divi ceļi uz vienu un to pašu instanci
Tiešais ceļš izmanto private-services-access maršrutu no jūsu tīkla uz projekta VPC. Jūsu klients runā PostgreSQL ar instances privāto adresi, un savienojums dzīvo vai mirst atkarībā no maršrutēšanas, firewall noteikumiem un datubāzes akreditācijas datiem.
Proxy ceļš izmanto to pašu maršrutu, bet pievieno lokālu procesu. Proxy autentificējas Google API ar jūsu lietojumprogrammas default credentials, atver savienojumu ar instanci caur konektoru un nodrošina loopback portu, ko jūsu klients uztver kā PostgreSQL. Divi lēcieni kļūst par trim, un vidējais nes IAM autorizāciju. VPN maršruts joprojām ir jūsu uzturēšanas atbildība, un proxy to nekad neuzskata par šīs pārbaudes aizstājēju.
Ko katrs ceļš patiešām autorizē
Vissvarīgākā atšķirība ir tas, ko katra iespēja var autorizēt jūsu vietā:
| 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 pārbaude un pierakstīšanās datubāzē ir divi atsevišķi vārti, un izeja caur vieniem neatver otru. Komanda, kas ieslēdz proxy un pieņem, ka lietojumprogrammas konts vairs nav vajadzīgs, pavadīs pēcpusdienu pie paroles kļūdām, kurām nav nekāda sakara ar tīklu.
Porti un maršruti, līdzās
Proxy nepieciešams izejošais TCP 443 API un TCP 3307 instances savienojumam, abi aprakstīti Google Auth Proxy pārskatā. Jūsu VPN maršruts sedz otro; pirmais parasti iziet pa parasto ceļu.
Tiešam savienojumam ir nepieciešams, lai instances PostgreSQL ports būtu sasniedzams pa privāto maršrutu, un tā ir pavisam cita firewall saruna. Ja jūsu tīkla komanda atļauj tikai izejošo 443 no klientu apakštīkliem, proxy iekļaujas bez noteikuma maiņas, bet tiešais ceļš ne. Šis vienīgais fakts izšķir izvēli biežāk nekā jebkura arhitektūras izvēle.
Neviens no ceļiem neprasa, lai instancei būtu publiska adrese, un neviens neattaisno tādas pievienošanu.
Kur proxy nepalīdz
Proxy nelabo trūkstošo maršrutu. Ja private-services-access maršruts nav, vai VPN to nenodrošina, konektors sabrūk, kamēr vietējais klausītājs joprojām sēž un klausās, un tas ir mulsinošais aspekts.
Tas arī neaizsargā posmu starp jūsu lietojumprogrammu un proxy. Vienā klēpjdatorā šis posms ir loopback un viss ir kārtībā. Ja jūs piesaistāt klausītāju wildcard adresei, lai kolēģis tam var piekļūt, jūs esat uzbūvējis neautentificētu datubāzes vārteju un nosaucis to par ērtību. Turiet to uz loopback un ļaujiet kolēģim iegūt savus akreditācijas datus.
Un tas nepadara Private Service Connect un private services access savstarpēji aizstājamus. PSC instancei ir vajadzīga sava DNS kārtība un --psc izsaukums, nevis --private-ip forma.
Izvēlēties un pēc tam jebkurā gadījumā pārbaudīt
Izvēlieties proxy, ja vēlaties IAM ceļā, īslaicīgus akreditācijas datus un nekādas izmaiņas ienākošajā firewall.
Izvēlieties tiešo maršrutu, ja atbalstītam klientam jau ir spēcīgi datubāzes akreditācijas dati un tīkla komanda ir gatava atvērt portu. Jebkurā gadījumā pārbaudiet ar īstu vaicājumu, nevis veiksmīgu savienojumu: savienojieties, izpildiet vienu lasīšanu pret zināmu tabulu un apskatiet, ko serveris redz par jūsu sesiju.
Pēc VPN atkārtotas savienošanas uzskatiet beigušos akreditācijas datus, trūkstošo privāto maršrutu un datubāzes pierakstīšanās noraidījumu par trim dažādām kļūmēm. Tikai viena no tām ir tīkla problēma, un tikai viena drīkstētu kādreiz novest pie firewall noteikuma maiņas.