Transit Gateway partajat: cine deține rutele în AWS RAM
Partajarea prin RAM permite altui cont să atașeze un VPC, dar tabelele de rute, asocierile și propagările rămân la proprietarul gateway-ului. Aici este granița.
Partajarea unui Transit Gateway cu Resource Access Manager face un lucru anume: permite altui cont să apeleze un set definit de API-uri de atașare asupra unei resurse pe care nu o deține. Nu transferă gateway-ul, tabelele sale de rute sau dreptul de a decide cum este redirecționat traficul. Oamenii presupun contrariul pentru că atașarea apare în consola destinatarului și funcționează imediat, ceea ce pare proprietate. Mecanismul de dedesubt este o acordare de permisiune pe o resursă partajată, iar fiecare obiect copil rămâne în limitele contului proprietarului. Această separare explică majoritatea tichetelor de acces refuzat din jurul tranzitului partajat.
Ce deleagă de fapt partajarea
O partajare de resursă numește o resursă, un principal și o permisiune gestionată. Permisiunea enumeră acțiunile pe care acel principal le poate executa, iar pentru un Transit Gateway lista acoperă operațiile de atașare pe resursa partajată.
Orice în afara listei eșuează la API, nu în consolă, de aceea eroarea apare adesea la prima rulare a unui script.
Tabelele de rute, asocierile și propagările rămân la proprietar
Redirecționarea este decisă de trei obiecte copil: cu ce tabelă de rute este asociată o atașare, în ce tabele se propagă și ce rute conțin acele tabele. Documentația AWS privind partajarea afirmă că un destinatar nu poate crea, modifica sau șterge tabelele de rute ale gateway-ului de tranzit ori asocierile și propagările lor prin partajare. Acele apeluri aparțin contului proprietar. Un destinatar care are nevoie de o asociere nouă cere o schimbare administrativă, nu exercită o permisiune pe care a uitat să o activeze.
Tabelul de mai jos este separarea pe care o pun în documentele de proiectare, pentru că supraviețuiește schimbărilor de personal.
| Role | What it controls |
|---|---|
| Transit Gateway owner | The gateway, its route tables, associations and propagations; the Site-to-Site VPN attachment is created here. |
| VPC owner using the share | Its own attachment, subnet route tables and security policy for the workloads. |
| Shared-subnet participant | Workload traffic only, following routes the VPC owner already set. |
Citiți cu atenție rândul din mijloc: proprietarul VPC controlează rutele subrețelei sale, proprietarul gateway-ului controlează decizia centrală de redirecționare, iar o cale funcțională are nevoie de ambele. Niciunul dintre conturi nu o poate finaliza singur.
O cale, două conturi
Urmăriți un pachet de la un VPC spoke la un prefix local. Tabela de rute a subrețelei spoke trebuie să trimită acel prefix către atașarea gateway-ului de tranzit, ceea ce proprietarul VPC poate schimba. Apoi gateway-ul trebuie să aibă în tabelul asociat al atașării o rută care indică atașarea VPN, iar asta doar proprietarul o poate schimba. Traficul de retur are nevoie de oglinda ambelor. Dacă lipsește oricare parte, obțineți o cale pe jumătate instalată care pare o problemă de firewall.
Scrieți ambele modificări într-un singur tichet cu doi responsabili, altfel vor fi finalizate în săptămâni diferite.
Folosiți ID-uri de zonă de disponibilitate când plasarea contează
Numele zonelor sunt aliasuri locale contului. us-east-1a într-un cont nu este garantat aceeași zonă fizică precum us-east-1a în altul. Când proiectarea cere o atașare și o încărcare de lucru în aceeași zonă, comparați ID-urile AZ și notați-le.
Compararea numelor produce o diagramă care pare corectă și un profil de latență care nu este. Verificați asta în timp ce diagrama este încă desenată, nu după ce cineva a măsurat diferența.
Anularea partajării nu taie calea datelor
Eliminarea partajării pare o revocare, dar nu este o oprire imediată a traficului. AWS documentează că o atașare rămâne funcțională când gateway-ul nu mai este partajat. Permisiunea de a gestiona resursa dispare, în timp ce atașarea existentă continuă să redirecționeze până când cineva o șterge sau o dezactivează. Planificați revocarea în doi pași: eliminați partajarea, apoi atașarea, iar proprietarul îl execută pe al doilea.
Dacă partajarea este singurul dumneavoastră control, nu aveți control.
Păstrați împreună înregistrarea partajării și înregistrarea rutării
Două artefacte răspund la două întrebări diferite. Înregistrarea partajării spune cine poate lucra cu resursa. Tabelele de rute spun care rețele pot vorbi cu adevărat. Păstrați-le împreună cu aceeași listă de proprietari, altfel următorul incident începe cu cineva care demonstrează o permisiune ce nu a fost niciodată problema.
Apoi testați un flux în fiecare direcție și un prefix care ar trebui să rămână inaccesibil.