De mesh belt naar buiten, en niemand luistert mee
Naar binnen is jullie mesh nu Zero Trust: mTLS op STRICT, default op Deny. En naar buiten? Daar belt hij met wie hij wil.
- Datum
- Onderwerp
- Egress
- Bronnen
- 3
- Leestijd
- 2 min
- Versie
- Vertaling
outboundTrafficPolicy staat af fabriek op ALLOW_ANY. De sidecar geeft traffic naar onbekende externe doelen gewoon door. Elke library die een licentieserver aanroept, elke vergeten webhook: alles gaat naar buiten, niets daarvan staat in een inventaris. Tijdens een incident kunnen jullie niet eens zeggen wat normaal zou zijn.
Afbeelding als tekst
Vergelijking van twee egress-bedrijfsmodi: links ALLOW_ANY als fabrieksinstelling, een workload met sidecar waarvan rood gestippelde pijlen naar onbenoemde externe doelen leiden (licentieserver van een library, vergeten webhook, niemand weet het); rechts REGISTRY_ONLY als inventarisatieplicht met drie gelabelde paden naar ServiceEntry-vermeldingen voor betaal-API, SSO en telemetrie. Daaronder de drie klassiekers van ServiceEntry-hygiëne: protocol HTTP waar in werkelijkheid TLS overheen gaat; resolution NONE waar DNS hoort; wildcard-hosts waarmee de inventarisatie er geen is.
REGISTRY_ONLY draait dat om. De sidecar kent alleen nog wat in de registry staat, elk extern doel heeft een ServiceEntry nodig. Dat is minder een beveiligingsfunctie dan een inventarisatieplicht: voor het eerst moet iemand opschrijven waar het systeem naartoe praat, en de catalogus staat als YAML in Git.
De catalogus is maar zo goed als het onderhoud ervan. Drie fouten zie ik steeds weer: een poort als http gedeclareerd waar TLS overheen gaat, dan struikelt de proxy over traffic die hij zou moeten begrijpen. resolution: NONE waar DNS hoort, dan routeert de sidecar blind naar het adres waar de applicatie om vraagt. En host-patronen die zo breed zijn dat de inventarisatie er geen is. Een wildcard op een heel domein is geen vermelding, dat is een schouderophalen.
Ownership volgens de lijn uit report #4 en #6: een ServiceEntry met lokale werking hoort bij de tenant die het doel nodig heeft. Mesh-brede vrijgaven horen bij het platform. En tegen de ServiceEntry-lijken uit report #3 helpt alleen één eigenaar per vermelding, die hem ook weer mag verwijderen.
Voor beslissers is het één enkele vraag: bestaat de lijst van alle externe afhankelijkheden, en wie heeft die vrijgegeven? ALLOW_ANY betekent dat de lijst niet bestaat.
De reflex op dit punt is bijna altijd dezelfde: “Dan bouwen we er een egress-gateway voor.” Waarom dat op zichzelf geen beveiligingsconcept is, volgende week.
