Onderwerp
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
Iedere aanmelding van een persoon loopt via de toegangsvoorziening van de eigen cel, of via de directory voor apparatuur zonder OIDC. Dit onderwerp legt vast hoe clusters, platformdiensten en apparatuur zijn gekoppeld, welke factoren per rolsoort gelden, hoe lang sessies en toegangsbewijzen duren en hoe mislukte aanmeldingen worden begrensd.
Met één plek voor aanmelding gelden factoren, sessieduur en intrekking overal hetzelfde. Waar de rechten groot zijn, moet de tweede factor phishingbestendig zijn. Korte toegangsbewijzen en sessies beperken wat een gestolen of achtergelaten sessie waard is, en maken de norm voor intrekking haalbaar.
Ieder cluster en iedere platformdienst meldt personen aan via de toegangsvoorziening van de eigen cel, of via de directory als het product geen OIDC of SAML kent. Lokale aanmelding is uitgeschakeld, op de noodtoegang na. Clusters hebben alleen de toegangsvoorziening als identiteitsaanbieder.
Reden: één plek voor factoren en intrekking. Controle: een overzicht van de gekoppelde diensten in de inventaris en een test met een lokaal account per dienst.
Het platform gebruikt één centrale identiteitsaanbieder, via OIDC, SAML of LDAP, voor alle menselijke gebruikers.
Per cel is dat de toegangsvoorziening; apparatuur zonder OIDC of SAML gebruikt de directory.
Iedere afnemer heeft een eigen client of koppeling, zodat een fout in één koppeling geen rechten elders geeft. Een doelsysteem vertrouwt alleen de realm platform van de eigen cel, een vlootdienst die van de leidende cel. Teamgroepen geven geen rechten buiten de eigen naamruimten.
Per afnemer ligt vast hoe zij aanmeldt, welke rechten en isolatie gelden en welke noodtoegang er is.
| Afnemer | Aanmelding | Rechten en isolatie | Noodtoegang | Bijzonderheden |
|---|---|---|---|---|
| Platformclusters | OAuth met Keycloak, groups-claim | Groepen van de eigen cel, op het vlootcluster vlootbrede groepen; API alleen vanuit de platformpool | Certificaat-kubeconfig | Installatieaccount weg na beproefde noodtoegang |
| Gehoste clusters | Idem, in de clusterdefinitie | Teamgroepen alleen in de eigen naamruimten | Beheerkubeconfig via het clusterbeheer | Wijzigen alleen in de clusterdefinitie |
| Argo CD | oidcConfig naar Keycloak | role:readonly; schrijven via versiebeheer | Via het vlootcluster | Eigen sessie ten hoogste 1 uur; alleen vanuit de platformpool |
| Forgejo | OIDC met groepsclaim; lokale aanmelding uit | Groepen van teamleden en teameigenaren gekoppeld aan teams, zodat alleen de teameigenaar een wijzigingsvoorstel van zijn team laat samenvoegen | Lokale beheerder | SSH-sleutel per persoon voor ondertekening |
| Quay, NetBox, Developer Hub, Ansible Automation Platform, Advanced Cluster Security, OpenBao | OIDC via Keycloak | Groepen naar productrollen | Beginaccount in de kluis; OpenBao via het quorum van herstelsleutels | Robotaccounts en API-tokens zijn technische identiteiten |
| midPoint en de gateway | OIDC via Keycloak | Beheer van midPoint alleen verhoogd; de beheeringang alleen voor platformrollen, de teamingang alleen voor actieve verhoogde teamgroepen | Lokale beheerder; noodwerkplek | Iedere ingang een eigen client |
| Ceph-dashboard | OIDC via de beheergateway | Rol read-only voor platformbeheer | Volgens het opslagcluster | Terugvaloptie SAML 2.0 |
| iLO en OneView | Directory (LDAPS) | Groepen door midPoint beheerd in de directory | Lokale beheerder | Alleen vanuit de platformpool |
| NetScaler, switches en fabriccontroller | AAA-voorziening van netwerkbeheer, tweede factor via de beheerwerkplek | Volgens het ontwerp van het netwerk en de externe verkeersverdeling | Lokale beheerder | — |
| Eigen bewakingsvoorziening | Eigen exemplaar van Keycloak, gevuld door het identiteitsbeheer | Alleen de groepen voor bewaking en onderzoek | Noodaccount in de kluis | Groeipadstap 2 |
| Platformautomatisering | Serviceaccounts; toegangsbewijzen uit het geheimenbeheer | Per taak en per cel | — | Ten hoogste 15 minuten per stap |
OpenShift meldt aan via de ingebouwde OAuth-server met Keycloak als OpenID-aanbieder, met mappingMethod claim en de groups-claim. Bij gehoste clusters staat die koppeling in de clusterdefinitie.
Afgewezen alternatief: rechtstreekse externe OIDC. Die kent één aanbieder, schakelt de OAuth-server en het installatieaccount uit en is bij gehoste besturing niet de standaard. Het past alsnog zodra de leverancier haar daar als standaard levert.
Apparatuur zonder OIDC, zoals iLO en het firmwarebeheer, meldt aan via de directory. Directorybeheer richt daarvoor een eigen organisatie-eenheid in, als deel van de dienstafspraak; midPoint beheert daarin de groepen met rechten op iLO en het firmwarebeheer, met een account dat alleen daar schrijft. Zo blijft de autorisatie uit het identiteitsbeheer komen.
Ieder doelsysteem staat met aanmeldvorm, client, groepen en noodtoegang in de inventaris; wat niet is geregistreerd, wordt niet aangesloten. Per cel worden de client-id’s, de terugverwijsadressen, de groepen en de koppelingen met apparatuur vastgelegd.
Controle: de inventaris naast de clients van de realm.
De toegangsvoorziening en de aangesloten diensten volgen het koppelprofiel OpenID.NLGov; een afwijking wordt met uitleg vastgelegd.
Reden: een open standaard. Getoetst per koppeling.
Iedere aanmelding vraagt twee factoren. De eerste is het wachtwoord van het RWS-account, gecontroleerd door de directory, zodat geen tweede wachtwoord ontstaat. De tweede factor hangt af van de rolsoort, elk in een eigen aanmeldstroom: WebAuthn of een authenticatorapp voor teamrollen, alleen WebAuthn met een hardwaresleutel of passkey voor platformrollen en alleen een hardwaresleutel voor vlootbrede rollen. Codes via sms of e-mail worden niet gebruikt.
Reden: phishingbestendig waar de rechten groot zijn. Voorwaarden bij de acceptatie: de directory controleert ook het wachtwoord van een account dat midPoint heeft aangemaakt, en vlootbrede rollen komen alleen met een hardwaresleutel binnen. Terugvalopties: wachtwoordloos aanmelden met passkey of hardwaresleutel, waarbij het identiteitsbeheer de sleutel voor de aanmeldstroom van vlootbrede rollen alleen bij de uitgifte van de hardwaresleutel registreert. Noodaccounts hangen niet van de directory af. Controle: een periodieke export van de realminstellingen naast de referentie, en per aanmeldroute een test met een account zonder tweede factor. Binnen een opgenomen sessie geldt de aanmelding in de sessie.
Toegang op afstand tot de API verloopt via TLS 1.2 of hoger, met meerfactoraanmelding bij de identiteitsaanbieder.
Sessies verlopen na 15 minuten inactiviteit en aanmeldsessies na ten hoogste 8 uur; toegangsbewijzen gelden kort. Geen client krijgt langere waarden.
| Onderdeel | Instelling | Waarde |
|---|---|---|
| Keycloak | SSO Session Idle | 15 minuten |
| Keycloak | SSO Session Max | 8 uur |
| Keycloak | Access Token Lifespan | 5 minuten |
| OpenShift | accessTokenInactivityTimeout | 15 minuten |
| OpenShift | accessTokenMaxAgeSeconds | 3600 (1 uur) |
| Gateway van de beheerwerkplek en iLO | Inactiviteit | 15 minuten |
| Eigen sessies van diensten, zoals Argo CD | Maximale duur | 1 uur |
Reden: achtergelaten sessies. Controle: de OpenShift-waarden met de compliancecontrole via het profiel rws-bio2, de Keycloak-waarden met de vergelijking van de realminstellingen.
Na 5 mislukte pogingen blokkeert de toegangsvoorziening het account tijdelijk, oplopend tot ten hoogste 15 minuten; de teller gaat na 15 minuten terug. Iedere mislukte aanmelding gaat als gebeurtenis naar het SOC.
Reden: raden begrenzen. Het SOC meldt herhaald mislukte aanmeldingen; zie de meetwaarden in Toezicht, taakverdeling en beproeving. Controle: een test met een testaccount.