Toegestaan is wat niemand heeft verboden
Na de ombouw naar STRICT uit de vorige aflevering is elke verbinding in de mesh versleuteld en wederzijds geauthenticeerd. Klinkt alsof het doel bereikt is. Alleen: elke workload mag nog steeds met iedereen praten.
- Datum
- Onderwerp
- AuthorizationPolicy
- Bronnen
- 3
- Leestijd
- 2 min
- Versie
- Vertaling
mTLS beantwoordt de identiteitsvraag. Geautoriseerd is daarmee helemaal niets. Zolang er geen AuthorizationPolicy bestaat, laat Istio elke geauthenticeerde call door. De facturatieservice mag het admin-endpoint van het buurteam aanroepen, netjes versleuteld, met een geldig certificaat. De audit-log ziet er voorbeeldig uit, de segmentatie ontbreekt desondanks volledig.
Afbeelding als tekst
De AuthorizationPolicy-evaluatie als stroomdiagram in drie stappen: een geauthenticeerde request doorloopt eerst CUSTOM (externe autorisatie, indien geconfigureerd), dan DENY (expliciete verboden, één treffer beëindigt alles), dan ALLOW (positieflijst, als er een bestaat). Rood gemarkeerd is de stille default: bestaat er geen ALLOW-policy, dan blijft de request toegestaan en loopt hij buiten de hele controle om. Daaronder het patroon (een lege ALLOW-policy per namespace zet de default op Deny) en de valkuil (alleen gestapelde DENY-policies zetten geen default).
De evaluatielogica in drie stappen: eerst lopen de CUSTOM-policies (externe autorisatie), dan alle DENY-policies, dan de ALLOW-policies. Matcht een DENY, dan is het afgelopen. Bestaat er voor de workload geen ALLOW-policy, dan wordt de request toegestaan. Bestaat er minstens één en past er geen, dan wordt hij geweigerd.
In die laatste zin zit het patroon: een lege ALLOW-policy per namespace, helemaal zonder regels, matcht niets en zet daarmee de default op Deny. Vanaf dat moment is elk toegestaan pad een bewuste, leesbare beslissing. De typische valkuil werkt andersom: wie alleen DENY-policies stapelt, verbiedt losse gevallen en heeft nog altijd geen default. Alles zonder DENY-treffer blijft open.
De ownership-vraag kennen jullie uit report #4 en #6, die geldt hier onveranderd: policies met lokale werking horen bij de tenant, die weet wie zijn service mag aanroepen. De mesh-brede default hoort bij het platform.
Voor beslissers: een firewall die standaard alles doorlaat, zou niemand in een netwerkreview aftekenen. In de mesh staat precies deze toestand vaak jarenlang in productie, met een compliance-vinkje erbovenop.
Verboden is wat iemand heeft verboden. De rest loopt.
Eerlijke vraag aan de groep: hoeveel van jullie namespaces zouden vandaag al een default-deny-policy hebben, als jullie het nu nakijken?
