Pirmo reizi mūžā taisu nelielu prezentāciju par relatīvi tehnisku tēmu. Šoreiz API gateway patterns - kas tas ir, ko tas risina, ko no tā vajag šodien, ko vajadzēja jau vakar, ko vajadzēs rīt, ko nevajadzēs nekad.
@laacz tvītu arhīvs
Sakarā ar to, ka Twitter ir slēdzis bezmaksas piekļuves savam API, šis projekts var tikt uzskatīts par mirušu sākot ar 2023. gada 15. jūniju.
Šis ir tvitera pavediens. No senākā uz svaigāko. Tvītu skaits: 65
@laacz **ieinteresēti skatās** tas kaut kādam slēgtam lokam, vai techies no malas arī būtu iespēja uzzināt?
@kakj Slēgtam lokam, jo komercnoslēpums ;)
@laacz Ko kā risinājumu izmanto ?
@KristapsKulis Pagaidām neko. Principā jau self hosted (F)OSS ir tikai 3 varianti. Plus ceturtais - DIY.
@laacz DIY API gateway - tas jau tā diezgan hardcore. Ja tur vēl pieslēgt JWT validāciju / transformācijas tad vispār kosmoss. Es par Azure API management varu teikt tikai labus vārdus (pagaidām)
@KristapsKulis Transformācijas kā reizi ir ārpus scope. Ja vajag, tad parasti tās uztaisam paši. Lielo kombainu nevajag darbināt, ja ir pāris gadījumi.
@laacz Ja ir procesu integrācijas platforma, tad tur tās transformācijas tiešām vajadzīgas īsti nav. Bet nu rate-limiting, JWT validācija, autentifikācija & autorizācija ir diezgan must-have, kas mikroservisu arhitektūrā ļauj nerakstīt kodu simts reizes
@KristapsKulis Un, kas attiecas uz JWT, tā nav liela raķešu zinātne. Protams, jāiespringst. API GW pielietojums manā gadījumā ir reducēts uz iekšējām lietām. Ar pārējo lai cīnās integrācijas slānis (arī manā lauciņā).
@KristapsKulis Jā, protams, mikroservisi un routings, JWT, autentifikācija & autorizācija ir tieši tas, kāpēc tagad pētu šo jautājumu. Bet, kā jau minēju iepriekšējā tvītā, labā ziņa - viss aiz APIGW sēdošais ir mūsu pašu veidots. Legacy paliek legacy, bet jaunajām izstrādēm būs būt labāk.
@laacz Par FOSS īsti nezinu, bet Azure API management services ir opcija developeru portāls, kas ļauj caur to pašu portālu testēt API un uztur shēmas / dokumentāciju
@KristapsKulis Mākonis mums nav opcija.
@laacz Nu jā, telco bija compliance prasības diezgan daudz ko hostēt pie sevis. Ja kas, ir arī MS Arc :)
@KristapsKulis BTW, paštaisītam ir viens milzīgs mīnuss. Eventuāli risinājums kļūst par tik šauri specializētu, ka vairs nav iespējams vienkārši aiziet uz veikalu un ar relatīvi nelielām pūlēm nopirkt vietā komerciālu vai FOSS risinājumu.
@laacz tur būtu jābūt ļoti spēcīgiem "argumentiem", lai mūsdienās FOSS vai komerciāla risinājuma vietā taisītu savu API management.
@KristapsKulis @laacz Ar transformācijām ir domāts data mappings? Jeb, iesūtam {"key1": "data"} un padodam tālāk {"keyX": "data"} ?
@gintsmurans @KristapsKulis Ne tikai. Piemēram, triviāls piemērs- legacy SOAP servisu notransformēt uz vienkāršāku RESTful. Nedaudz sarežģītāks - dažādu API composition, lai klienta pieprasījuma rezultātā izsauktu čupiņu iekšējo, apkopotu atbildi un atgrieztu. Utt.
@gintsmurans @KristapsKulis Es gan no šī izvairīšos līdz pēdējam, jo tas jau ir enterprise integration layer lauciņš, kurā sanāktu iekāpt.
@laacz @KristapsKulis I see. Tikai neredzu kā diy variantā tas būtu apzīmējams ar vārdu "hardcore". Pieļauju, ka ikdienā taisot datu sūtīšanu šurpu turpu starp dažādām sistēmām, tas vairs neliekas sarežģīti. Mums ir legacy sistēma uz mysql bāzes no kuras sūtam datus uz MS f&o,
@laacz @KristapsKulis gan api veidā - python diy api serviss + diy X-API-Key autorizācija, gan savācot datus no mysql, "transformējot" un sūtot prom izmantojot MS data entities.
@gintsmurans @KristapsKulis Nu, transformācijas parasti ir additional layer, kas nav vienkāršs paitona skripts. Pilnvērtīgā API GW tas parasti ietver savu templeitingu, dažādus rūļus, cieši integrējas ar pārējām lietām (policies), urļu prefetčings un atdošana caur API, utt. Tur ir DAUDZ.
@gintsmurans @KristapsKulis Rekur piemēri - MS: https://learn.microsoft.com/en-us/azure/api-management/api-management-transformation-policies - AWS: https://docs.aws.amazon.com/apigateway/latest/developerguide/models-mappings.html - KONG: https://konghq.com/blog/api-gateway-request-transformation
@laacz @gintsmurans Azure vismaz var kaut kādu limitētu dotNET apjomu bliezt iekšā policy.
@laacz @KristapsKulis Grūti ātrumā iedomāties gadījumus, kad tas viss ir vajadzīgs. Tev ir kāds piemērs?
@gintsmurans @KristapsKulis Tu neesi saskaries ar tipiskiem enterprise sistēmu integrāciju izaicinājumiem :)
@laacz @KristapsKulis Es ar visu ko esmu saskāries, arī ar to, ka ļoti bieži lietas tiek pasniegtas sarežģītākas nekā tās patiesībā ir, kā rezultātā tiek ietirgotas lielas, dārgas, neefektīvas sistēmas ar ntajiem layeriem, kuras jāliek uz dārgiem dzelžiem, lai tās spētu pavilkt. Par kurām ir
@laacz @KristapsKulis jāmaksā lielas mēnešmaksas un tāpat kādam ir jāuztur. Lai arī tā vietā varēja uztaisīt vienkārši saprotamu struktūru, uzrakstot vienkāršu mapping modeli, kādā no populārākajām programmēšanas valodām.
@gintsmurans @KristapsKulis Tu vari uzturēt izstrādes komandu, veltīt šim cilvēkus, plānot, deployot, atrast ownerus, kas beigu galā ar to vien nodarbosies, kā veidos savu inhouse integrācijas slāni. Bet ir rīki, kas piedāvā to darīt tajos. Katram variantam ir savu plusi uh savi mīnusi.
@laacz @KristapsKulis Protams, katru gadījumu var izvērtēt. Ja šādas integrācijas nākotnē taisās daudz būt, varbūt izdevīgāk ir vienu cilvēku uzņēmumā algot tikai uz šo integrāciju veidošanu. Izmantojot gatavus rīkus, tāpat kādam būs jāzin kā šos rīkus izmantot + vēl jāmaksā par licencēm.
@gintsmurans @KristapsKulis Ja runa ir par API gateway, tam ir FOSS risinājumi.
@laacz @KristapsKulis Par api gw runājot. Radās vajadzība piekļūt api servisam no ārpasaules, kas ir zem uzņēmuma fw. Pa tiešo fw negribējās vērt vaļā, jo ip adreses tiek regulāri skenētas. Radās risinājums: nginx proxy <-> 127.0.0.1:xxxx <-> ssh tunelis <-> api serveris
@laacz @KristapsKulis ar ssh tuneli un port forwardingu uz api servisu un ssh konekcijas monitoringu, kas nebija baigi uzticams, līdz ar to tapa serviss, kas pingo otru galu un ja kas norestartē tuneli. FOSS risinājums. 😁
@gintsmurans @KristapsKulis Neņem ļaunā, bet šis izklausās pavisam nelabi. To sauc par hacku. Neuzturams, dīvains, utt. Parasti to risina ar VPN.
@laacz @KristapsKulis Ārējā piekļuve bija vajadzīga MS F&O - vpn neiespējams. No linux vpn grūti kontrolējams, bieži problēmas, neatbalsta to un šito chiperi un veidu. Ssh viegli saprotams, vienkāršs, strādā ar visām openssh implementācijām bez specifiskām fw prasībām. Publiskam api gan tā nedarītu.
@gintsmurans @laacz Kur problēma atvērt servisu no IP adrešu whitelista ? Tāpat SSH ir jāatver :)
@KristapsKulis @laacz No ārpuses uz iekšu nav jāatver - tur jau tā būtība.
@gintsmurans @laacz Nu ja nav opcija uztaisīt normālu s2s vpn, tad attaisa uz IP adresēm un miers. Šādi risinājumi agrāk vai vēlāk radīs agresijas lēkmi cilvēkam, kam to nāksies uzturēt.
@KristapsKulis @laacz Tāpēc serveru konfigurāciju glabājam iekš ansible, lai citi varētu saprast kas kur notiek un attiecīgais risinājums būtu re-deployable,ja nu rodas vajadzība. Vispār SSH tuneļi ir pārāk "maznovērtēta" fīča. Var atrast ntos pielietojuma veidus kā vienkārši,bet droši pārsūtīt datus.
@gintsmurans @laacz AFAIK nav īsti iespējams normāli kontrolēt, ko tā SSH konekcija galu galā dara, tā kā nekas tur baigi drošs tas nav.
@gintsmurans @KristapsKulis Automātiski ceļami SSH tuneļi papildus tam visam ir nenovērtēti drošības caurumi.
@laacz @gintsmurans AFAIK tur nevarēja tā "by policy" kontrolēt kurā galā un kādā režīmā tas tunelis strādā, gribēji servisu exposot, beigās sanāca SOCKS proxy :>
@laacz @KristapsKulis Ir gan, ja zin kā izmantot. 😅 Bet ja nevar uzticēties darbiniekiem, kas risinājumu programmē, tad tur nav vērts vispar par drošību domāt. tad ir jānoslēdz pilnīgi viss no abām pusēm, jāatver iekš fw porti un jācer, ka pašā aplikācijā nebūs problēmas.
@laacz @KristapsKulis Bankā strādājot bija tāds cietuma režīms, neapskaužu.
@gintsmurans @laacz lielākā daļa kriptouzbrukumu pēdējā laikā organizācijām ir bijuši caur partneri, kas mazāk aizsargājas un kuram ir savienojums ar organizāciju. Tā nu arī aizsargājas :)
@KristapsKulis @laacz Šajā gadījumā viss ir iekšēji kontrolēts - kādi porti forwardēti, publiskajā pusē nobindoti uz 127.0.0.1, nginx forwardē tikai atļautos endpointus. Publiski ekspozēti 80 un 443 porti. Tunelis ir site to site līmenī - nav vajadzīga nekāda lietotāju atļauju politika. Otrā virzienā
@KristapsKulis @laacz pieslēgties nav iespējams. Protams ja kāds uzlauž pašu publisko serveri, tad var mēģināt dabūt ko vairāk apejot nginx, bet nginx ir tikai vēlviens layeris, nevis drošības vārti. Būtībā viss tāpat kā ar vpn, pat labāk, jo var tikt klāt tikai forwardētajiem portiem.
@KristapsKulis @laacz Protams vpn gadījuma var salikt tiesības ka x var tikt tikai y klāt, bet tā ir atkal vēlviena vieta kura jāuztur bez pārējām vpn problēmām.
@KristapsKulis @laacz Kopumā domāju ka vpn ir nedrošāks risinājums, jo visi vpn rūļi parasti ir sarakstīti kopā vienā čupā ar visu pārējo fw, kas rada lielāku iespēju pieļaut kļūdas kaut ko mainot. Kaut vai velkot rūļus uz augšu un leju var nepamanīt ka esi ielicis vispirms atļaut visu.
@gintsmurans @laacz Normāli tiek definēti savi rūļi katram tunelim, tur nekāds allow all nesanāks :)
@gintsmurans @KristapsKulis Salti meli.
@laacz @gintsmurans Nu tas ir stipri atkarīgs no FW administratora roku leņķa. Normāli katrs VPN ir sava zona ar saviem ruļiem.
@laacz @KristapsKulis Par kuru daļu? 😅
@KristapsKulis @gintsmurans Mēs taču nerunājam par idiotiem. Mēs runājam par risinājumiem. Drošiem, pārvaldāmiem, nododamiem, saprotamiem, vispārzināmiem, labpraksīgiem.
@KristapsKulis @laacz Pieļauju, ka tā nav liela problēma pavisam lielajos uzņēmumos, kur ir jātiek pie 5 atļaujām un jāraksta procedūra par katra ieraksta maiņu. 🥹😅
@gintsmurans @laacz Tas protams ir pilnīgi atkarīgs no uzņēmuma partneru skaita. Ar vienu, diviem vai pat desmit var pahackot, bet kad skaits aiziet simtos...
@gintsmurans @KristapsKulis Procesi, procedūras, kārtība ir tieši tāpēc, lai to visu ir vieglāk pārvaldīt, lai viss nekļūst "ai, man šitā ērtāk" punktveida risinājumu paradīzi. Un te es nerunāju par galējībām. Tam visam jāpalīdz, nevis jātraucē.
@KristapsKulis @laacz Simtos partneru dot vpn ieeju? Šis nebūs tas gadījums. Ja jādod 100+ partneriem vpn pieeja, tad ir jāņem atsevišķa ierīce, kas dara tikai vpn konekciju uzturēšanu un rūļu menedžēšanu. Tas ir pilnībā cits scope's.
@laacz @KristapsKulis Izklausas, ka vējš pūš no enterprise puses, kur viss tiek kontrolēts, viss taisīts 100% pēc specifikācijas, kreativitātei nav vietas, visam jāprasa atļauja. Izklausas baigi neinteresanti. Ssh tunelim nav ne vainas no drošības viedokļa, pieņemot, ka tas ir pareizi izdarīts. Tikai
@laacz @KristapsKulis tas, ka IT daļa nevar izkontrolēt kādi porti tiek atvērti. Tur laikam tā lielā sāpe. Bet ir tāda lieta, kamēr vieni cīnās ar birokrātiju, citi pārsūta datus drošā veidā. Ja vajadzīgas izmaiņas - jauns ports, pirmajā gadījumā atkal tā pati birokrātija, atļaujas, utt, otrā gadījumā
@laacz @KristapsKulis config faila maiņa, ssh procesa restarts un gatavs - 5 minūtes. Ja ir iezīmes, ka nevar darbiniekiem uzticēties, ka uzliks papildus portus un darīs ko sliktu, nu tad ir bēdīgi, tad par to ir jādomā.
@gintsmurans @KristapsKulis Man ir žēl, ka Tev vienīgais uzskats par modernu un palielāku uzņēmumu ir tāds.
@laacz @KristapsKulis Tāda nu tā pieredze ir, jo uzņēmums paliek lielāks, jo vairāk viss tiek ierobežots, lielāka birokrātija, arvien vairāk laika pavadi gaidot uz kādu citu, nevis reāli radot risinājumus.. Un tas ir pašsaprotami, arvien vairāk cilvēku, ne visi ir normāli čaļi.
@laacz @KristapsKulis Bet teikt, ka ssh tunelis ir nedrošs un neuzturams risinājums, mja.. Gribētu redzēt tavu risinājumu savā darba vietā, iekšēja api servisa (kur dati nāk no vairākām iekšējām datubāzēm) pieeju no ārpuses. Es pat shēmu uzzīmēju. Uzreiz varu pateikt, ka X1 nav konkrētas ip.
@gintsmurans @KristapsKulis Noformulēju. Es pats arī ikdienā lietoju SSH tuneļus un nesmādēju. Taču to mērķis ir būt īslaicīgiem palīgiem un nekādi ne automātiskiem pastāvīgiem risinājumiem. Ne velti trafika enkapsulācijai izmanto tieši VPNus.