STD-0006: Containerisatie en orkestratie¶
Documentgegevens¶
| Versie | Datum | Evaluatiedatum | Scope |
|---|---|---|---|
| 0.1 | 2026-08-25 | 2027-08-25 | Platformbreed |
Doel en reikwijdte¶
Deze standaard beschrijft de voorwaarden waaronder containerized deployment veilig en beheersbaar is. Containerisatie is geen verplicht doel. Zij geldt alleen wanneer een geschiktheidsanalyse aantoonbaar waarde laat zien en het operationele model de extra platformcomplexiteit kan dragen.
Normatieve bepalingen¶
- Voor containerisatie MOET een geschiktheidsanalyse plaatsvinden op workloadtype, licentie, OS/hardware-afhankelijkheid, state, gegevensvolume, performance, security, support, kosten en exitstrategie.
- Legacy-, appliance-, desktop- en sterk stateful workloads MOGEN een ander deploymentmodel gebruiken wanneer dat aantoonbaar geschikter is.
- Containerimages MOETEN minimaal, immutable, herleidbaar en gescand zijn en BEHOREN non-root te draaien.
- Images MOETEN worden opgebouwd en gepromoveerd volgens STD-0005.
- Workloads MOETEN betekenisvolle startup-, readiness- en livenesssignalen bieden.
- Readiness MOET verkeersontvangst sturen; liveness MAG NIET worden misbruikt om afhankelijke of trage systemen onbeperkt te herstarten.
- Startup en shutdown MOETEN graceful verlopen binnen een configureerbare termijn.
- Duurzame gegevens en processtate MOGEN NIET uitsluitend in vluchtige containerlagen staan.
- Resource requests en limits MOETEN op metingen worden gebaseerd.
- Applicatielogica BEHOORT gestandaardiseerde orchestratorcapaciteiten te gebruiken zonder onnodige verankering aan één product.
Rationale¶
Containers kunnen packaging, automatisering, isolatie en schaalbaarheid verbeteren, maar creëren ook runtime-, registry- en orchestratiebeheer. De geschiktheid verschilt per workload; een algemene containerplicht zou onnodige complexiteit en kosten veroorzaken.
Uitzonderingen en risicoacceptatie¶
Een afwijking van runtime- of image-eisen MOET workload, beperking, risico, compenserende maatregel, eigenaar en eind- of evaluatiedatum bevatten. Een keuze om niet te containeriseren is geen afwijking wanneer de geschiktheidsanalyse een ander model aanbeveelt.
Naleving en vereiste bewijslast¶
- gedocumenteerde geschiktheidsanalyse;
- image-inventaris, SBOM, scan- en provenancebewijs;
- non-root- en filesystemcontrole;
- tests van probes, startup, shutdown en nodeverlies;
- resource- en schaalmetingen;
- bewijs van externe duurzame state of gedocumenteerde stateful inrichting.
Implementatieprofielen¶
Een later platformprofiel MOET registry, toegestane base images, signing, runtimebeveiliging, netwerkbeleid, secretintegratie en orchestrator vastleggen. Deze standaard kiest geen specifiek containerplatform.
Externe mappings en bronnen¶
| Kader | Versie | Control(s) | Relatie | Status |
|---|---|---|---|---|
| ISO/IEC 27002 | 2022 | 8.9, 8.20, 8.27 | Configuratie, netwerkbeveiliging en veilige architectuur | Ondersteunend |
| BIO2 | 1.3 | 8.9, 8.20, 8.27 | Overheidsbaseline | Ondersteunend |
| NEN 7510-2 | 2024+A1:2026 | 8.9, 8.20, 8.27 | Zorgspecifieke aansluiting | Te valideren |
Wijzigingshistorie¶
| Versie | Datum | Wijziging |
|---|---|---|
| 0.1 | 2026-08-25 | Eerste concept, omgezet van voorgestelde ADR naar standaard. |