ABB: 2.2.0.1 Management Cluster(s)

Dienstbeschrijving

De dienst Management Cluster(s) fungeert als centrale hub om meerdere clusters te beheren (updates, policies, monitoring) over datacenters, cloud en edge/OT. RWS hanteert een Red Hat Advanced Cluster Management (ACM) hub als primaire besturingslaag en kan, waar schaal of scheiding dat vereist, een “hub of hubs”‑architectuur inzetten (meerdere domein‑/regiohubs aangestuurd door een centrale overkoepelende hub).

Doel en scope

• In scope: hub‑gebaseerd fleetbeheer (creëren/importeren van clusters), policy‑/governance‑handhaving, lifecycle & upgrades (ring‑gebaseerd), multi‑cluster observability, applicatie‑plaatsing, integraties met GitOps/ITSM/CMDB/SIEM/Kostbeheer, en (optioneel) service‑connectiviteit tussen clusters.

• Niet in scope: applicatieontwikkeling, low‑level cloudnetwerkdesign, en beheer van niet‑gekwalificeerde K8s‑distributies.

Waardepropositie

• Uniform & schaalbaar: één besturingsvlak voor tientallen tot honderden clusters.

• Veilig & aantoonbaar compliant: centrale policies (BIO/AVG/CIS) met evidence en auto‑remediatie.

• Efficiëntie & snelheid: ring‑gebaseerde upgrades, herbruikbare profielen en geautomatiseerde rapportage.

• Robuust: hub of hubs voor domeinscheiding, fault isolation en federatieve besturing.

Dienstonderdelen

1. ACM‑hub (beheer‑/governance‑laag) en Multi‑Cluster Observability (MCO).

2. Hub of hubs (optioneel): overkoepelende besturing en consolidatie van compliance/telemetrie.

3. GitOps‑koppeling voor declaratieve distributie van apps/policies.

4. Integraties met OCM/HCC, IAM/PKI/KMS, ITSM/CMDB, SIEM/Observability, Kostbeheer.

Servicelevels (richtwaarden)

Functionele Specificaties

Onderstaande eisen beschrijven wat de dienst levert. AC = acceptatiecriteria.

Hub‑architectuur & topologie

• FS‑HUB‑001 ACM‑hub
  Eis: Een hoogbeschikbaar ACM‑hubcluster in Twin‑DC met gescheiden admin en read‑only rollen.
  AC: Hub verliest geen state bij node‑/zone‑uitval; 100% admin‑acties gelogd.

• FS‑HUB‑002 Hub of hubs
  Eis: Ondersteuning voor meerdere domein‑/regiohubs met consolidatie naar een centrale hub (compliance/telemetrie/plaatsingsbesluiten).
  AC: Geen dubbele handhaving; duidelijke ownership per hub; latency targets gehaald.

• FS‑HUB‑003 BCP/DR
  Eis: Back‑up/restore van hub‑state en draaiboek voor hub replace.
  AC: DR‑oefening slaagt ≥ 99%; RTO/RPO conform platform‑SLA.

Onboarding & lifecycle

• FS‑LIFE‑001 Create/import
  Eis: Declaratieve creatie of import van clusters (DC/edge/cloud) met baseline labels/policies.
  AC: Succesratio import ≥ 99%; baseline toegepast binnen 10 min.

• FS‑LIFE‑002 Upgrades (ring‑gebaseerd)
  Eis: Release‑channels en canary→waves met preflight checks en automatische pauze bij fouten.
  AC: Geen upgrades tijdens ‘blackout’; rollback < 2 min via policy/Git.

Governance, policies & evidence

• FS‑GOV‑001 Policy‑bundels
  Eis: Herbruikbare bundels (BIO/AVG/CIS) per omgeving/tenant; enforce of audit mode.
  AC: Policy‑scan slaagt; exceptions hebben eigenaar en einddatum.

• FS‑GOV‑002 Auto‑remediatie
  Eis: Standaarddrift automatisch herstellen of isoleren.
  AC: ≥ 95% standaarddrift hersteld; overig gelogd met runbook.

• FS‑GOV‑003 Evidence & audit
  Eis: Onveranderbare evidence exporteerbaar naar SIEM/auditors; retentie ≥ 13 maanden.
  AC: Volledige trace (wie/wat/wanneer/waarom) per policy‑wijziging.

Applicatie‑plaatsing & netwerk (optioneel)

• FS‑APP‑001 Placement rules/decisions
  Eis: Declaratieve plaatsing over clusters op basis van labels (regio/site/tier/capaciteit).
  AC: 0% misplaatsing in canary‑tests; health‑gates gerespecteerd.

• FS‑APP‑002 Multi‑cluster connectiviteit
  Eis: Gestandaardiseerd profiel voor service discovery/verbindingen (bijv. Submariner‑achtig).
  AC: Latency/bandbreedte binnen SLO; segmentatie‑policies blijven actief.

Observability & telemetrie

• FS‑OBS‑001 Fleet‑health
  Eis: Centrale dashboards/alerts; consolidatie van MCO‑metriek per hub en hub of hubs.
  AC: MTTD kritieke events < 5 min; retentie ≥ 13 maanden.

• FS‑OBS‑002 Kost/energie‑signalen
  Eis: Koppeling naar Kostbeheer (OpenCost/Kepler) voor fleet‑inzicht.
  AC: Maandrapport per tenant/cluster; afwijkingen >10% gemarkeerd.

Security & toegang

• FS‑SEC‑001 SSO/RBAC & least privilege
  Eis: Toegang tot hub(s) via SSO/RBAC; scheiding view vs admin; PAM voor break‑glass.
  AC: 100% admin‑acties gelogd; periodieke recertificatie.

• FS‑SEC‑002 Supply chain
  Eis: Enforce image signing/attestaties op alle clusters via policies.
  AC: Niet‑ondertekende images geweigerd; evidence beschikbaar.

Integraties & edge/disconnected

• FS‑INT‑001 GitOps/ITSM/CMDB
  Eis: GitOps voor app/policy distributie; automatische changes en CI‑updates.
  AC: CI bijgewerkt ≤ 24 uur; drift detect ≤ 5 min.

• FS‑EDGE‑001 Disconnected beheer
  Eis: Mirrors/caches en queue‑based synchronisatie voor edge; lokale handhaving actief.
  AC: Geen policy‑schendingen tijdens offline vensters (≤ 48 uur); veilige resync.

Roadmaps

Mijlpaal 1

• Primaire ACM‑hub in Twin‑DC operationeel; import van eerste DC/edge/cloud‑clusters; baseline policy‑bundels en centrale dashboards.

• Start ring‑upgrades met canary‑clusters; GitOps‑koppeling voor policies/apps.

Mijlpaal 2

• Domein‑/regiohubs opgezet waar schaal/segregatie dat vereist; begin hub of hubs consolidatie (compliance/telemetrie).

• Auto‑remediatie voor standaarddrift; maandelijkse fleet‑rapportages naar ITSM/SIEM.

Mijlpaal 3

• Federatieve plaatsing over hubs; optionele multi‑cluster connectiviteit voor geselecteerde use‑cases; geautomatiseerde failover‑simulaties.

• DR‑oefeningen voor hub‑vervanging; performance‑optimalisaties voor >100 clusters.

Mijlpaal 4

• Volwassenheidsfase: self‑healing hub‑landschap (drift detect & repair), voorspellende upgradeplanning en standaard evidence‑pakketten.

• Samenwerking met (waar toegestaan) andere overheden via gedeelde policy‑profielen en federatieve modellen.

Landingslocaties

Waar de architectuuronderdelen landen binnen de infrastructuur, dit kan bijvoorbeeld een externe commerciële cloud zijn, een private cloud of een Rijkscloud. Hiervoor wordt de definitie in de ICT Strategie gebruikt.

Beschikbare SBBs 

Een overzicht van de oplossingen die beschikbaar zijn vanuit dit ABB en de beschrijving van de diensten die daarmee worden geleverd. Vul dit in wanneer de SBBs bekend zijn.

Koppelvlakken

Interfaces en afhankelijkheden tussen verschillende architectuurelementen. Dit zijn bijvoorbeeld de protocollen die kunnen worden gebruikt door andere bouwblokken die gebruik maken van het ABB.

Afhankelijkheden

Beschrijving waar dit ABB van afhankelijk is of welke ABBs afhankelijk zijn van het ABB. Dit geldt ook voor de verschillende serviceketens. Geef dit aan met links naar de architectuur elementen.

EIRA Koppeling

Dit bouwblok is gekoppeld binnen de EIRA aan: Vul hier de EIRA koppeling in.

Een overzicht van alle relevante EIRA bouwblokken staan hier: EIRA Technology & Physical