Publicatie, namen en TLS

Bij het publiceren van een versleutelde dienst onderhandelt de client TLS met het werkelijke TLS-eindpunt. De verkeersverdeling bezit het dienstcertificaat niet en verandert de hybride sleuteluitwisseling van TLS 1.3 niet.

Achter de verkeersverdeling ziet de ingang als bron het adres naar achteren van het paar in het ingangssegment, zonder X-Forwarded-For of PROXY-protocol. De verkeersverdeling legt per verbinding clientadres, virtueel adres en doel vast, en het SOC correleert de logboeken van client, virtueel adres en doel.

Ieder applicatiecluster krijgt twee virtuele adressen, elk met een eigen virtuele server en een gezondheidscontrole: api voor de besturing op TCP 6443, naar het API-adres van de gehoste besturing op het clusterbeheer, en apps voor toepassingen op TCP 443, naar het ingangsadres van het cluster in zijn eigen VLAN. Er is geen contentswitch; de namen zijn api.<naam> en *.apps.<naam>.

Achter iedere virtuele server staat één doeladres dat alleen die dienst bedient. Iedere gepubliceerde platformdienst en iedere gedeclareerde verbinding met een eigen poort krijgt een eigen virtueel adres en een eigen doeladres; een generieke clusteringang mag geen extra consoles of beheerroutes bereikbaar maken.

Het gemeenschappelijke paar publiceert naast de applicatieclusters ook de platformeindpunten, elk met een eigen doeladres: de API-publicatie op het clusterbeheer, het portaal, de toegangsvoorziening voor de aanmelding van teams, de aanmeldroutes van de gehoste besturingen voor OAuth, Konnectivity en Ignition, de teamingang van de beheerwerkplek en het ontvangstpunt van het bouwcluster, dat alleen GitLab bereikt. Consoles, standaard- en beheeringangen en de API van het clusterbeheer blijven onbereikbaar.

De ingangscontroller van een applicatiecluster is een LoadBalancer-dienst met een adres van MetalLB in het VLAN van de werkers, alleen voor HTTPS op 443. Zij sluit TLS af met het standaardcertificaat *.apps.<naam>.<cel>.dc3.internal uit de tussen-CA van de cel, of geeft TLS bij een passthrough-route ongeopend door aan de toepassing, die dan zelf het TLS-eindpunt is. De ingangscontroller is niet rechtstreeks bereikbaar.

De gezondheidscontrole van een virtuele server is een TCP-handshake op de doelpoort, los van het TLS-profiel van het doel: zij bewijst dat de poort bereikbaar is, en een afzonderlijke dienstproef controleert TLS en de toepassing. De servicegroep, het doel achter een virtuele server, toont of een gepubliceerd cluster bereikbaar is. Naar achteren controleert de verkeersverdeling geen certificaat, naam of intrekking; ook het certificaat van de API-server gaat ongemoeid door.

Een publicatie wordt op het actieve lid van het paar ingericht en naar het andere lid gesynchroniseerd; daarna worden de namen geregistreerd en wordt zij vanuit een kantoornetwerk beproefd. In het leverpad volgt zij op de standaardinrichting van het cluster en ontstaat zij binnen de normtijd van 1 uur per stap. Bij intrekking verdwijnen virtuele servers, servicegroepen, namen en een eventueel publiek certificaat, vóór de volumes van het cluster.

Mislukt het aanleggen van een publicatie of koppeling, dan verwijdert het draaiboek al het aangelegde: in verkeersverdeling, bron, netwerk en identiteitsbeheer blijft niets achter. Een gedeeltelijk mislukte levering krijgt de status ‘Onvolledig’ met de ontbrekende stap, en het beheer hervat haar zonder dubbele regels of objecten.

Namen en adressen worden vóór publicatie toegewezen in Infoblox en geregistreerd in NetBox; wat daar niet vooraf staat, wordt niet gepubliceerd. De automatisering maakt de namen api.<naam> en *.apps.<naam> aan onder <cel>.dc3.internal, met de adressen uit Infoblox.

De namen api.<naam> en oauth.<naam> staan in twee weergaven van Infoblox: interne vragers gaan rechtstreeks naar het API-adres op het clusterbeheer, overige vragers naar het virtuele adres op de verkeersverdeling. API-namen blijven celgebonden, ook bij de overname van een bedrijfskritische dienst.

Namen buiten het RWS-netwerk staan onder een publiek domein van netwerkbeheer, in een met DNSSEC ondertekende zone. Een wijziging van publieke namen of reeksen gaat binnen 14 dagen naar het entiteitenregister.

De eerste levering publiceert alleen interne namen; het eerste team publiceert niet buiten RWS. De publieke keten wordt met een testnaam aangetoond bij de acceptatie van de ingang. Publicatie buiten het RWS-netwerk komt als veld in de dienstbeschrijving vanaf de vrijgave voor reguliere productie, voor diensten in reguliere en bedrijfskritische productie, met per naam een certificaat uit de externe PKI in de naamruimte van de route.

Op de ingangscontroller van ieder cluster geldt het TLS-profiel: TLS 1.2 en 1.3 aan, oudere versies uit, met de algoritmelijst volgens de cryptografietabel van RWS; dus TLS 1.3, of TLS 1.2 met de toegestane algoritmen. Een HTTP-route voert HSTS. De API-server heeft een eigen profiel, en de verkeersverdeling heeft er geen.

Bescherming tegen overbelasting is geborgd met limieten en quota: de verkeersverdeling begrenst het aantal verbindingen per virtuele server, en de ingang past per route een tempogrens toe die voor alle clients samen geldt. HSTS staat per route op de ingang. Het gebruik is per paar en per afnemer zichtbaar, en iedere capaciteitsgrens heeft een actiedrempel.

Certificaten worden centraal beheerd via de PKI en staan bij de ingang of de dienst, nooit op de verkeersverdeling. Voor interne namen komen zij uit de tussen-CA van de cel, voor de dienstnaam van een bedrijfskritische dienst uit de tussen-CA ‘vloot’ en voor namen buiten het RWS-netwerk per naam uit de externe PKI. Zij gelden ten hoogste 90 dagen, worden bij twee derde van de looptijd zonder onderbreking vervangen en 30 en 7 dagen vóór het verlopen gemeld.

cert-manager in het cluster van de ingang of de dienst geeft interne certificaten uit via een ClusterIssuer van het type vault naar de PKI van OpenBao: een Certificate per ingang voor het standaardcertificaat, en in de teamnaamruimte voor een passthrough-route. De terugvaloptie is uitgifte via de API van OpenBao. Er wordt nooit een eigen certificaat ingesteld voor api-int. Interne clients vertrouwen de interne PKI, externe clients de publieke wortel.

Een publiek certificaat komt per naam uit de externe PKI, via een ACME-uitgever of het RWS-aanvraagproces. Een draaiboek plaatst het zonder onderbreking als geheim in de naamruimte van de route, met de sleutel in het geheimenbeheer, en vernieuwt het. Een dagelijkse vergelijking controleert de geplaatste certificaten en toetst het entiteitenregister; een afwijking gaat naar platformbeheer en een afwijkende inrichting als melding naar het SOC.

Sleutels van publieke certificaten, beheeraccounts van de paren en geheimen van leesaccounts staan alleen in het geheimenbeheer en worden na een mogelijke compromittering binnen 24 uur vervangen.

De cryptografie volgt per pad de cryptografietabel van RWS en staat in het cryptografieoverzicht. Alle dienstprofielen gebruiken dezelfde tabel, zonder MD5-opties, en het platform draait niet in FIPS-modus: algoritmen, sleutelgroottes en protocollen worden per pad ingesteld en getoetst, want een productlabel is geen bewijs voor het volledige pad. Waar een product het ondersteunt, geldt TLS 1.3, anders TLS 1.2 met algoritmen uit de tabel; OpenBao en PostgreSQL hebben TLS 1.3 als minimum.

De hybride quantumveilige sleuteluitwisseling van TLS 1.3 (X25519MLKEM768) blijft ingeschakeld waar het product haar biedt: bij API-server, kubelet en ingangscontroller zet het platform haar niet uit. De verkeersverdeling laat die onderhandeling tussen client en ingang ongemoeid. Etcd biedt haar niet; het dienstennetwerk krijgt haar bij een gekwalificeerde ingebruikname.

Een TLS-scan bevraagt ingangen en API’s per naam via de virtuele adressen, ook na overschakeling naar het tweede lid van een paar, en ziet alleen TLS 1.2 en 1.3 met de toegestane algoritmen. Zij controleert het onderhandelde protocol, de cryptografie, de certificaatketen en de geldigheid; vernieuwing, intrekking en negatieve tests horen bij de acceptatie. Maandelijks toont een TLS- en poortscan vanuit een kantoor- en een applicatienetwerk aan dat ingangsadressen, werkers, API-adressen en beheeradressen niet rechtstreeks bereikbaar zijn.