Cloud SQL Auth Proxy ընդդեմ դեպի տվյալների բազա ուղիղ VPN երթուղու
Auth Proxy-ն և ուղիղ VPN երթուղին լուծում են նույն խնդրի տարբեր կեսերը։ Նախ համեմատեք connector-ի լիազորումը, պորտերը և տվյալների բազա մուտքը։
VPN-ում գտնվող նոութբուքից մասնավոր Cloud SQL ինստանս հասնելու երկու ողջամիտ եղանակ կա։ Առաջինը ուղիղ կապն է ինստանսի մասնավոր հասցեին այն երթուղու միջոցով, որն արդեն ունեք։ Երկրորդը Cloud SQL Auth Proxy-ն է, որը լսում է loopback-ում և ինքն է բացում կապը դեպի Cloud SQL։ Սրանք ավելի քիչ մրցակից ապրանքներ են, քան երկու տարբեր պատասխան այն հարցին, թե ով է պահում վկայականը և ով է պահում երթուղին։ Սխալ ընտրությունը սովորաբար ի հայտ է գալիս որպես լիազորման սխալ, որը կարդացվում է որպես ցանցի սխալ։
Ահա այն համեմատությունը, որը կդնեի թիմի առաջ, և դրանից հետո այն ստուգումները, որոնք իրականում որոշում են։
Երկու ուղի դեպի նույն ինստանս
Ուղիղ ուղին օգտագործում է private-services-access երթուղին ձեր ցանցից դեպի նախագծի VPC։ Ձեր client-ը PostgreSQL-ով խոսում է ինստանսի մասնավոր հասցեի հետ, և կապը ապրում կամ մահանում է երթուղավորման, firewall կանոնների և տվյալների բազայի վկայականների վրա։
Proxy ուղին օգտագործում է նույն երթուղին, բայց ավելացնում է տեղային գործընթաց։ Proxy-ն նույնականացվում է Google API-ի հետ ձեր հավելվածի default credentials-ով, connector-ի միջոցով կապ է բացում ինստանսի հետ և տրամադրում loopback պորտ, որը ձեր client-ը դիտարկում է որպես PostgreSQL։ Երկու թռիչք դառնում է երեք, և միջինը կրում է 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-ին անհրաժեշտ է ելքային TCP 443 API-ի համար և TCP 3307 ինստանսի կապի համար, երկուսն էլ նկարագրված են Google-ի Auth Proxy-ի ակնարկում։ Ձեր VPN երթուղին ծածկում է երկրորդը, առաջինը սովորաբար դուրս է գալիս սովորական ուղով։
Ուղիղ կապը պահանջում է, որ ինստանսի PostgreSQL պորտը հասանելի լինի մասնավոր երթուղով, ինչը բոլորովին այլ firewall զրույց է։ Եթե ձեր ցանցային թիմը թույլատրում է միայն 443 ելք client ենթացանցերից, proxy-ն տեղավորվում է առանց կանոնի փոփոխության, իսկ ուղիղ ուղին՝ ոչ։ Այդ մեկ փաստը որոշում է ընտրությունը ավելի հաճախ, քան ցանկացած ճարտարապետական նախընտրություն։
Ուղիներից ոչ մեկը չի պահանջում, որ ինստանսն ունենա հանրային հասցե, և ոչ մեկը չի արդարացնում այդպիսին ավելացնելը։
Որտեղ proxy-ն չի օգնում
Proxy-ն չի շտկում բացակայող երթուղին։ Եթե private-services-access երթուղին բացակայում է, կամ VPN-ն այն չի տեղափոխում, connector-ը ձախողվում է, մինչ տեղային լսողը դեռ այնտեղ նստած լսում է, և հենց դա է շփոթեցնող մասը։
Այն նաև չի պաշտպանում ձեր հավելվածի և proxy-ի միջև ընկած հատվածը։ Մեկ նոութբուքի վրա այդ հատվածը loopback է և կարգին։ Եթե լսողը կապեք wildcard հասցեի, որպեսզի գործընկերը հասնի դրան, դուք կառուցել եք չնույնականացված տվյալների բազայի դարպաս և այն անվանել հարմարավետություն։ Պահեք այն loopback-ի վրա և թող գործընկերը ստանա իր սեփական վկայականը։
Եվ այն Private Service Connect-ը և private services access-ը չի դարձնում փոխարկելի։ PSC ինստանսին պետք է իր սեփական DNS կարգավորումը և --psc կանչը՝ --private-ip ձևի փոխարեն։
Ընտրել, ապա ամեն դեպքում ստուգել
Ընտրեք proxy-ն, երբ ուզում եք IAM ուղու վրա, կարճաժամկետ վկայականներ և ոչ մի փոփոխություն մուտքային firewall-ում։
Ընտրեք ուղիղ երթուղին, երբ աջակցվող client-ն արդեն ունի ուժեղ տվյալների բազայի վկայականներ, և ցանցային թիմը պատրաստ է բացել պորտը։ Ամեն դեպքում ստուգեք իրական հարցումով, ոչ հաջող կապով. միացեք, կատարեք մեկ ընթերցում հայտնի աղյուսակից և տեսեք, թե ինչ է տեսնում սերվերը ձեր սեսիայի մասին։
VPN-ի վերակապումից հետո ժամկետանց վկայականը, բացակայող մասնավոր երթուղին և տվյալների բազա մուտքի մերժումը դիտարկեք որպես երեք տարբեր ձախողում։ Դրանցից միայն մեկն է ցանցային խնդիր, և միայն մեկը երբևէ պետք է հանգեցնի firewall կանոնի փոփոխության։