Netwerkbeleid en uitgaand verkeer

Een beheerdersbeleid (AdminNetworkPolicy, prioriteit 10–20) weigert op alle clusters verkeer naar platformnaamruimten, behalve DNS en de ingang, en verkeer tussen naamruimten van verschillende afnemers volgens de zonecontrole; teams kunnen het niet overschrijven. Een basisbeleid (BaselineAdminNetworkPolicy met de naam default) weigert als vangnet verkeer tussen naamruimten, met lagere voorrang dan het netwerkbeleid van een team. Het vlootbeheer dwingt beide af.

Iedere naamruimte heeft een NetworkPolicy die alles weigert, plus toestaan vanaf de ingang en naar DNS. Teams voegen alleen gedeclareerde verbindingen toe: hun NetworkPolicies komen uit de dienstbeschrijving. Wie uitgaand verkeer weigert, zondert DNS uit, alleen naar de DNS-dienst van het cluster.

Secundaire interfaces, zoals de opslagaansluiting van werkers, en het hostnetwerk vallen buiten het netwerkbeleid van het cluster. Zij mogen alleen als de dienstbeschrijving ze vermeldt, en worden in het datacenternetwerk begrensd met filterregels en toegangslijsten.

Een beleidswijziging wordt kort na het samenvoegen gehandhaafd, niet ogenblikkelijk; die tijd wordt gemeten. Het bewijs is een nalevingsoverzicht en een test met een niet-gedeclareerde verbinding, met een eigen toestaanregel van een team, ook een teambeleid dat alles toestaat, en met een secundaire interface.

Iedere teamnaamruimte heeft een EgressFirewall met de naam default: de toegestane bestemmingen uit de dienstbeschrijving, als dnsName of cidrSelector met poort, afgesloten met een regel die 0.0.0.0/0 weigert. Weigeringen gaan via ACL-logging naar het SOC. Applicatieclusters hebben geen route naar internet, en de proxy dient alleen de beheerwerkplek, het spiegelen en de toelatingsroute.

Twee lagen begrenzen uitgaand verkeer, elk met eigen bewijs: de EgressFirewall laat per naamruimte alleen de gedeclareerde bestemmingen toe, en het firewallcluster alleen de stroom van de clusterreeks. De firewall ziet alleen het adres van de werker; het onderscheid tussen naamruimten maakt dus de EgressFirewall. Hostnetwerk, verkeer via de router en secundaire interfaces vallen alleen onder de filterregels. EgressIP wordt in de eerste levering niet gebruikt.

Het netwerk van een applicatiecluster is gereed wanneer een gedeclareerde verbinding werkt, een niet-gedeclareerde verbinding wordt geweigerd en gemeld, uitgaand verkeer naar een niet-toegestane bestemming wordt geblokkeerd en een missiekritieke zone vanuit het cluster alleen via een voorgeschreven koppelvlak bereikbaar is.

Het netwerk van een applicatiecluster wordt met het cluster geleverd, in de varianten die netwerkbeheer heeft goedgekeurd en het ontwikkelteam inricht. Verkeer is standaard dicht; een team declareert een verbinding en het platform doet de rest.

In het sjabloon van de eerste levering is alleen de standaardvariant te kiezen. Een bestaand netwerkverband is een uitzondering, het afgeschermde applicatienetwerk zit niet in het sjabloon, en EVPN vanuit clusters volgt pas in de fase van route-aankondiging en EVPN vanuit clusters.

Een afgeschermd applicatienetwerk is een UserDefinedNetwork per naamruimte, als Layer2 of Layer3 met de rol Primary. Het label k8s.ovn.org/primary-user-defined-network wordt bij het aanmaken van de naamruimte gezet en is daarna onveranderbaar.

Een bestaand netwerkverband loopt op de werkervirtualisatie als ClusterUserDefinedNetwork Localnet met het VLAN van het bestaande verband. Op fysieke clusters is het, vanaf de fase van EVPN vanuit clusters, een ClusterUserDefinedNetwork Layer2 met transport EVPN: een tunneleindpunt met adressen uit VLAN 660, een FRRConfiguration met de toegangsswitches als BGP-buren, een macVRF met het VNI uit de registratie en ipam lifecycle Persistent. VNI en VLAN komen uit de datacenterregistratie.

Een behouden laag-2-netwerkverband blijft binnen één cel en heeft een terugvalpad. Het is een uitzondering met eigenaar, terugvalpad en een einddatum van ten hoogste zes maanden, vastgelegd in een ontwerpbesluit en in het uitzonderingsregister.

Het doel is de lichte vorm van het dienstennetwerk, met één besturing en één vertrouwensdomein per cel, per naamruimte in te schakelen na schriftelijke productondersteuning en beproeving in de leeromgeving en de proefgroep. Het herkent de tegenpartij per applicatie-identiteit en versleutelt het verkeer tussen deelnemende naamruimten; netwerkregels blijven nodig en de ontvangende dienst beslist nog steeds over lezen en schrijven. Daarna geldt ook binnen het dienstennetwerk standaard weigeren: per naamruimte een AuthorizationPolicy met ALLOW-regels op principal, afgedwongen in reguliere productie en eerst als dry run bij ontwikkelen en beproeven.

Zolang het dienstennetwerk ontbreekt, is ieder onversleuteld pad een uitzondering per verkeersstroom, met eigenaar en een einddatum van ten hoogste zes maanden; dat geldt ook voor iedere onversleutelde stroom door de ingang of een koppeling. Bij de vrijgave voor reguliere productie zijn deze uitzonderingen gesloten of door de CISO-functie opnieuw geaccepteerd, met een nieuwe einddatum.

TLS of wederzijdse TLS wordt toegepast op al het interne en externe verkeer.

Werklastisolatie wordt afgedwongen met SELinux in afdwingende modus, sandboxing van pods of containers en beperkte security context constraints.

Werklasten kunnen geen onverwachte of gevaarlijke dynamische code laden.

Sessies zijn beschermd met kortlevende tokens, TLS en een geharde OAuth-configuratie.

De configuratiedatabase van de clusters en alle persistente gegevens zijn versleuteld.