Het portaal en de ontwikkelomgeving

Er is één portaal voor de hele vloot, op het portaalcluster portaal-prd-c1-01 in cel 1. Het houdt geen gezaghebbende gegevens en is voor geen cel een voorwaarde om te werken of te herstellen. Na verlies van cel 1 wordt het in cel 2 herbouwd, na het versiebeheer, met namen onder het domein van cel 2; het herstel duurt ten hoogste 8 uur.

Developer Hub draait met twee exemplaren op verschillende werkers, geïnstalleerd met de operator en een Backstage-resource, met de app-configuratie in ConfigMaps. Het heeft een eigen database op CloudNativePG met drie exemplaren en de waarden van een beheerde database voor reguliere productie; die database is niet gezaghebbend. Het portaalcluster heeft drie tot zes virtuele werkers van maat M, in verschillende rekken.

App-configuratie en rolbeleid komen als bestanden uit de opslagplaats Platform; de interface van het portaal kan geen rollen wijzigen. De RBAC-plug-in staat aan met beleid per rol voor teamontwikkelaar, teameigenaar en platformbeheerder. Die rollen komen als groepen uit de toegangsvoorziening; het portaal controleert ze aan de serverzijde, en de toetsing doet dat opnieuw.

Aanmelding bij portaal en ontwikkelomgeving loopt via de toegangsvoorziening met meerfactoraanmelding, met OIDC naar Keycloak; ook gebruikers en groepen in de catalogus komen uit Keycloak. Sessies verlopen na 15 minuten inactiviteit en na 8 uur, en een intrekking werkt binnen 1 uur. Platformbeheer beheert het portaalcluster via de beheerwerkplek met tijdelijk verhoogde rechten.

Het portaal toont en wijzigt alleen gegevens van het eigen team, ook via de API; de status toont alleen de diensten van het eigen team.

Iedere technische identiteit van portaal, toetsing en leverwerkstroom heeft een eigenaar, één taak en geen interactieve aanmelding. Het portaal heeft een repositorygebonden token dat leest in Catalogus en Afnemers en voorstellen maakt in Afnemers, en een leesidentiteit op het vlootcluster voor de statusplug-in; het kan niet samenvoegen, de takbeveiliging niet wijzigen en niets uitvoeren.

Dienstbeschrijvingen, sjablonen en portaal bevatten geen geheimen. De langlevende geheimen van het portaal, dus de twee tokens, het clientgeheim bij de toegangsvoorziening en het databasewachtwoord, zijn geregistreerd als beheerde langlevende geheimen: ze komen via External Secrets uit het geheimenbeheer en worden iedere 30 dagen vervangen, met overlap of binnen een gedateerde onderbrekingsuitzondering, waarbij de exemplaren na elkaar herstarten.

Developer Hub heeft geen ondersteunde koppeling met Forgejo. Een sjabloon haalt daarom de dienstbeschrijving op met de stap fetch:template en maakt dan met een eigen sjabloonstap via de API van Forgejo een tak, de vastlegging en een pull request in Afnemers. De catalogus leest de locaties uit de opslagplaats Catalogus via de Gitea-integratie van Backstage, met regels per soort.

Het portaal toont de voortgang uit de leverstatus en de toestand uit het vlootbeheer, elk met het tijdstip van de laatste bijwerking, en daarnaast documentatie en het scanrapport van de softwarelevering. De clusterstatus komt via een statusplug-in met een leesidentiteit op het vlootcluster.

Catalogus, portaal en leverpad hebben deze interfaces.

Het portaalcluster is een gehost cluster met een platformfunctie. Werkers en ingang staan in het routeringsdomein platform (vrf-platform), met het werkernetwerk op een eigen segment uit VLAN 700–709 (L2-VNI 10700–10709), MTU 9000 en een /26 uit de platformreeks; de werkers krijgen hun adres via DHCP-doorgifte naar Infoblox. Het portaal is bereikbaar vanuit kantoor en WAN, alleen binnen het RWS-netwerk, onder interne namen van de cel.

Het portaal is alleen bereikbaar via doorgifte door het gemeenschappelijke paar van de externe verkeersverdeling: TCP 443, zonder TLS-afsluiting, naar een eigen ingangsshard die alleen portaal en ontwikkelomgeving bedient en de console en andere routes niet. De ingangsshard sluit zelf TLS af, met het TLS-profiel van de baseline, een standaardcertificaat van cert-manager uit de tussen-CA van de cel en HSTS.

Catalogus, portaal en leverpad hebben deze verbindingen; uitgaand verkeer van portaal en werkruimten gaat alleen naar de bestemmingen in deze lijst.

Werkruimten zijn de enige werklasten op het portaalcluster die code van teams uitvoeren, en zij staan zonder firewall in het routeringsdomein van de basisdiensten. Het netwerkbeleid weigert daarom hun verkeer naar de naamruimten van het portaal, en hun lijst van toegestane bestemmingen sluit vrf-platform uit, behalve de containerregistry. Uitbreidingen komen alleen uit het vrijgegeven beeld of de spiegel. Een werkruimte stopt na 15 minuten zonder activiteit, en een gebruiker heeft één actieve werkruimte.

Portaal, werkruimtebeelden en dynamische plug-ins komen alleen als vrijgegeven software uit de containerregistry van de cel.

Catalogus, portaal en leverpad gebruiken deze producten, op een gehost cluster met OpenShift 4.22 en virtuele werkers.

Upgrades volgen het bijwerken per laag, met operators op een vast kanaal en handmatige goedkeuring. Het portaalcluster krijgt een nieuwe OpenShift-versie als gehost cluster van cel 1 in golf 1, na de leeromgeving, de platformclusters en de proefgroep, en pas als Developer Hub en Dev Spaces die versie ondersteunen. Portaal en ontwikkelomgeving hebben geen exemplaar in de proefgroep: hun nieuwe versie gaat na de leeromgeving met golf 1 naar productie.