Hoofdstuk 1 — Inleiding: SOC 2 in een Kubernetes-tijdperk

Steeds meer organisaties draaien hun productieomgevingen op Kubernetes-gebaseerde platformen: vanilla Kubernetes, Red Hat OpenShift, of het Nutanix Kubernetes Platform (NKP). Tegelijkertijd vragen klanten, partners en investeerders steeds vaker om een SOC 2-rapport als bewijs dat een organisatie zorgvuldig omgaat met beveiliging, beschikbaarheid en gegevensbescherming.

Dat roept een praktische vraag op: hoe vertaal je de abstracte eisen van SOC 2 naar concrete, technische maatregelen in een containerplatform? Dit boek beantwoordt die vraag door SOC 2 stap voor stap te koppelen aan de specifieke mogelijkheden — en beperkingen — van OpenShift, Kubernetes en NKP.

Dit boek is geen vervanging voor een formele audit of juridisch advies. SOC 2-attestatie wordt uitgevoerd door een onafhankelijke registeraccountant (CPA-firma in de VS, of een vergelijkbare auditor); dit boek helpt platformteams en security-verantwoordelijken zich daarop voor te bereiden door de technische controlemaatregelen te begrijpen en in te richten.

Hoofdstuk 2 — Wat is SOC 2? Type I versus Type II

SOC 2 (System and Organization Controls 2) is een auditstandaard ontwikkeld door het American Institute of Certified Public Accountants (AICPA), gericht op hoe een serviceorganisatie klantgegevens beheert. In tegenstelling tot bijvoorbeeld ISO 27001, dat een gecertificeerd managementsysteem toetst, resulteert SOC 2 in een rapport waarin een onafhankelijke auditor beoordeelt of de controlemaatregelen van een organisatie voldoen aan de gekozen Trust Services Criteria.

Type I versus Type II

Een Type I-rapport beoordeelt of de beschreven controles op een specifiek moment (een "point in time") op de juiste manier zijn ontworpen. Een Type II-rapport gaat een stap verder: het beoordeelt of die controles gedurende een observatieperiode (doorgaans 3 tot 12 maanden) ook daadwerkelijk consistent zijn uitgevoerd. Type II wordt door de meeste klanten en partners als het zwaarwegender bewijs gezien, juist omdat het aantoont dat controles niet alleen op papier bestaan.

Voor een Kubernetes-gebaseerde omgeving betekent dit concreet: een Type II-audit vereist dat je gedurende maanden bewijsmateriaal verzamelt — auditlogs, wijzigingshistorie via Git, scanresultaten, toegangswijzigingen — in plaats van pas vlak vóór de audit alles op orde te brengen.

Hoofdstuk 3 — De Trust Services Criteria in detail

SOC 2 is gestructureerd rond vijf Trust Services Criteria (TSC). Security is verplicht voor elk SOC 2-rapport; de overige vier zijn optioneel en worden gekozen op basis van wat relevant is voor de dienstverlening.

• Security (Common Criteria) — bescherming tegen ongeautoriseerde toegang, zowel fysiek als logisch. Dit omvat toegangscontrole, netwerkbeveiliging, wijzigingsbeheer en risicomanagement.
• Availability — systemen zijn beschikbaar voor gebruik zoals toegezegd, inclusief capaciteitsplanning, disaster recovery en incidentrespons.
• Processing Integrity — verwerking is volledig, geldig, accuraat, tijdig en geautoriseerd — relevant voor platformen die data transformeren of berekeningen uitvoeren.
• Confidentiality — informatie die als vertrouwelijk is aangemerkt (bijvoorbeeld broncode, klantcontracten) wordt beschermd gedurende de hele levenscyclus.
• Privacy — persoonsgegevens worden verzameld, gebruikt, bewaard en verwijderd in lijn met het gepubliceerde privacybeleid.

De Security-criteria (ook wel de "Common Criteria" genoemd, CC1 t/m CC9) vormen de kern waar dit boek zich grotendeels op richt, omdat zij het meest direct vertalen naar technische Kubernetes-controles: toegangsbeheer (CC6), systeembewerking (CC7), wijzigingsbeheer (CC8) en risicobeperking (CC9).

De negen Common Criteria in het kort

Dit boek richt zich vooral op CC6 t/m CC9, omdat deze het meest direct te vertalen zijn naar concrete Kubernetes/OpenShift/NKP-configuratie. CC1 t/m CC5 zijn minstens zo belangrijk voor een geslaagde audit, maar zijn primair organisatorisch van aard (governance, risicomanagement, communicatie) en minder platform-specifiek — daarvoor verwijzen we naar gespecialiseerde compliance-literatuur buiten de scope van dit technische boek.

Hoofdstuk 4 — Shared responsibility: wie is verantwoordelijk voor wat

Een veelgemaakte fout is aannemen dat een platform als OpenShift of NKP "SOC 2-compliant" is en dat daarmee de eigen verantwoordelijkheid vervalt. In werkelijkheid geldt, net als bij cloudproviders, een gedeeld verantwoordelijkheidsmodel.

De onderliggende infrastructuur (compute, storage, netwerkhardware) valt doorgaans onder de cloud- of hardwareleverancier. De Kubernetes/OpenShift/NKP-laag zelf — de distributie, patches en kernfunctionaliteit — is een gedeelde verantwoordelijkheid tussen leverancier en platformteam. De configuratie van die laag (RBAC-policy's, netwerkbeleid, secrets-beheer, admission control) is vrijwel altijd de verantwoordelijkheid van het eigen platformteam, ongeacht welk platform gebruikt wordt. Tot slot blijft de applicatie en de data die erin verwerkt wordt, altijd de verantwoordelijkheid van de organisatie zelf.

Hoofdstuk 5 — Architectuuroverzicht: OpenShift, Kubernetes en NKP naast elkaar

Voordat we per controlemaatregel induiken, is het nuttig de drie platformen op hoofdlijnen te vergelijken op de aspecten die het meest relevant zijn voor SOC 2.

Geen van de drie platformen is "gratis compliant" — elk vereist bewuste configuratie. Het verschil zit vooral in hoeveel er kant-en-klaar aanwezig is versus zelf opgebouwd moet worden, en hoeveel bewijsmateriaal (rapportages, logs) het platform automatisch genereert ten behoeve van een audit.

Hoofdstuk 6 — Toegangscontrole en identiteitsbeheer

Toegangscontrole (CC6 in de Common Criteria) is vrijwel altijd het zwaarst getoetste controlegebied bij een SOC 2-audit. De kernvraag: kan de organisatie aantonen dat alleen geautoriseerde personen toegang hebben tot systemen en data, en dat die toegang regelmatig wordt herzien?

Centrale identity-provider

Gebruik in alle drie de platformen een centrale identity-provider (LDAP, OIDC of SAML) in plaats van lokale gebruikersaccounts per cluster. Dit maakt het mogelijk om toegang op één plek in te trekken (bijvoorbeeld bij uitdiensttreding), en is een controle die auditors expliciet toetsen: hoe snel wordt toegang ingetrokken na een offboarding-melding?

RBAC: least privilege als uitgangspunt

Alle drie de platformen ondersteunen Kubernetes RBAC (Roles, RoleBindings, ClusterRoles). Het risico zit niet in het ontbreken van RBAC, maar in te ruime rollen: het toekennen van cluster-admin aan te veel gebruikers is een van de meest voorkomende bevindingen bij Kubernetes-audits. Werk met namespace-specifieke rollen, en reserveer clusterbrede rechten voor een klein, expliciet gedocumenteerd team.

Periodieke toegangsreview

SOC 2 verwacht een periodieke (doorgaans kwartaal) review van wie welke toegang heeft, met documentatie van de uitkomst. Automatiseer dit waar mogelijk: een periodiek rapport van alle RoleBindings en ClusterRoleBindings per gebruiker, gedeeld met de verantwoordelijke manager ter goedkeuring.

Voorbeeld: een namespace-specifieke rol in plaats van clusterbrede rechten

In plaats van een gebruiker cluster-admin-rechten te geven omdat "het makkelijker is", definieert onderstaand voorbeeld een rol die alleen leesrechten geeft binnen één namespace — precies het soort least-privilege-configuratie die auditors verwachten:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: productie-app
  name: readonly-viewer
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: readonly-viewer-binding
  namespace: productie-app
subjects:
  - kind: User
    name: jan.devries@voorbeeld.nl
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: readonly-viewer
  apiGroup: rbac.authorization.k8s.io

Documenteer voor elke ClusterRoleBinding met clusterbrede rechten expliciet wíe deze heeft, waaróm, en wanneer dit voor het laatst is herzien — dit is vaak letterlijk het eerste dat een auditor opvraagt bij het toetsen van CC6.1.

Multi-factor authenticatie

Voor toegang tot productieclusters — zowel via de webconsole als via kubectl/oc met een gekoppelde identity-provider — is MFA een veelgevraagde aanvullende controle, met name voor gebruikers met verhoogde rechten. Dit wordt doorgaans niet door het Kubernetes-platform zelf afgedwongen, maar door de gekoppelde identity-provider (OIDC/SAML).

Hoofdstuk 7 — OpenShift-specifiek: Security Context Constraints en Compliance Operator

Security Context Constraints (SCC)

SCC's bepalen welke rechten een pod mag opeisen: of hij als root mag draaien, welke Linux-capabilities zijn toegestaan, en welke SELinux-context wordt gebruikt. Standaard is OpenShift restrictiever dan vanilla Kubernetes — pods draaien standaard niet als root. Voor SOC 2 is dit direct bruikbaar bewijs voor CC6.1 (logische toegangsbeveiliging): het aantoont dat het platform standaard een restrictieve postuur hanteert in plaats van alles toe te staan en achteraf te beperken.

Compliance Operator

De OpenShift Compliance Operator scant clusters tegen erkende benchmarks (CIS Benchmarks, NIST 800-53, PCI-DSS) en genereert rapportages met afwijkingen. Dit is buitengewoon waardevol als doorlopend auditbewijs: in plaats van handmatig te documenteren dat een cluster aan een bepaalde baseline voldoet, levert de Compliance Operator geautomatiseerde, herhaalbare scanresultaten die direct als bewijsmateriaal aan een auditor kunnen worden overlegd.

Hoofdstuk 8 — Kubernetes-specifiek (vanilla): wat je zelf moet regelen

Bij een zelfbeheerde, vanilla Kubernetes-omgeving ontbreken de meeste kant-en-klare compliance-hulpmiddelen die OpenShift en NKP bieden. Dit betekent niet dat SOC 2-compliance onhaalbaar is, maar wel dat elk onderdeel bewust moet worden ingericht en onderhouden.

• Pod Security Admission — de opvolger van het verouderde PodSecurityPolicy; moet actief worden geconfigureerd met een baseline of restricted-profiel per namespace, anders draaien pods met vrijwel onbeperkte rechten.
• Authenticatie en autorisatie — vereist een zelf gekozen en geïntegreerde OIDC-provider; er is geen ingebouwde OAuth-server zoals bij OpenShift.
• Compliance-scanning — community-tools zoals kube-bench (CIS Benchmark-scanning) of kube-hunter moeten zelf worden geïntegreerd en periodiek uitgevoerd; er is geen ingebouwde operator die dit automatiseert.
• Auditlogging — de Kubernetes API server ondersteunt uitgebreide audit-logging, maar de configuratie (welke gebeurtenissen, welk detailniveau, waar de logs naartoe gaan) moet volledig zelf worden ingericht.
• Image-registry en scanning — een externe registry (Harbor, of een cloud-registry) met ingebouwde scanning moet apart worden opgezet; dit komt niet "gratis" mee.

Pod Security Standards in detail

Kubernetes definieert drie ingebouwde beveiligingsniveaus voor Pod Security Admission:

apiVersion: v1
kind: Namespace
metadata:
  name: productie-app
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Zonder deze labels accepteert een vanilla Kubernetes-cluster standaard vrijwel elke pod-configuratie, inclusief containers die als root draaien met vrijwel onbeperkte Linux-capabilities — precies het tegenovergestelde uitgangspunt van OpenShift's standaard restrictieve SCC's.

Hoofdstuk 9 — NKP-specifiek: ingebouwde compliance-features

Het Nutanix Kubernetes Platform (NKP, voorheen bekend als D2iQ Kubernetes Platform) positioneert zich nadrukkelijk als een "enterprise-ready" Kubernetes-distributie met compliance als expliciet aandachtsgebied.

• Voorgedefinieerde RBAC-templates — NKP levert kant-en-klare rolsjablonen (bijvoorbeeld cluster-viewer, cluster-admin, namespace-admin) die de meest voorkomende toegangsscenario's dekken zonder dat een team RBAC-manifests vanaf nul moet schrijven.
• FIPS-modus — voor organisaties die aan Amerikaanse overheidsstandaarden moeten voldoen, biedt NKP een FIPS 140-2-conforme configuratie-optie voor cryptografische modules.
• Geïntegreerde image-scanning — scanning van container-images op kwetsbaarheden is standaard onderdeel van de pipeline, in plaats van een losse, zelf te integreren stap.
• Centrale multi-cluster console — voor organisaties met meerdere clusters (bijvoorbeeld gescheiden per omgeving: dev, staging, productie) biedt NKP centraal overzicht van configuratie en afwijkingen, wat consistente controle over meerdere clusters vereenvoudigt.

Voor SOC 2-doeleinden is het belangrijkste voordeel van NKP niet dat het "compliance garandeert", maar dat het de consistentie tussen clusters vereenvoudigt — en consistentie is precies wat een Type II-audit toetst.

Hoofdstuk 9a — Verdieping: Compliance Operator-profielen en remediaties

De OpenShift Compliance Operator werkt met vooraf gedefinieerde "profielen" die corresponderen met erkende benchmarks. Het kiezen van het juiste profiel — en het begrijpen van wat een scan wel en niet automatisch oplost — is essentieel om dit onderdeel effectief in te zetten.

Van scanresultaat naar remediatie

Een scan levert per controle een van drie mogelijke uitkomsten: PASS (voldoet), FAIL (voldoet niet), of MANUAL (vereist menselijke beoordeling, bijvoorbeeld organisatorisch beleid dat niet technisch te verifiëren is). Voor een deel van de FAIL-resultaten kan de Compliance Operator een kant-en-klare remediation genereren: een Kubernetes-object dat, eenmaal toegepast, de afwijking automatisch corrigeert.

oc get complianceremediations -n openshift-compliance
oc patch complianceremediation ocp4-cis-api-server-audit-log-maxbackup 
  --type merge -p '{"spec":{"apply":true}}'

Niet elke remediatie is zonder risico automatisch toe te passen in productie — sommige wijzigen bijvoorbeeld API-server-instellingen die een korte herstart vereisen. Behandel remediaties daarom via dezelfde change-management-controle als elke andere productiewijziging (zie hoofdstuk 17), inclusief review en een geplande onderhoudsvenster waar nodig.

Hoofdstuk 9b — Verdieping: NKP multi-cluster governance

Organisaties met meerdere Kubernetes-clusters — bijvoorbeeld gescheiden per omgeving (ontwikkeling, test, productie) of per regio — lopen een specifiek compliance-risico: configuratie die correct is op cluster A, maar niet consistent is doorgevoerd op cluster B. Voor een SOC 2 Type II-audit is die inconsistentie problematisch, omdat de auditor niet één cluster maar de hele populatie beoordeelt.

Centrale policy-distributie

NKP's centrale console maakt het mogelijk om policy's (RBAC-templates, netwerkbeleid, admission-policy's) vanuit één plek te definiëren en te distribueren naar alle aangesloten clusters, met rapportage over welke clusters afwijken van de vastgestelde baseline. Dit is functioneel vergelijkbaar met wat Red Hat Advanced Cluster Management biedt voor OpenShift-omgevingen, en met wat bij vanilla Kubernetes doorgaans zelf moet worden opgebouwd via GitOps-tooling zoals Argo CD met een "app-of-apps"-patroon over meerdere clusters.

Consistente evidence over clusters heen

Voor auditdoeleinden is het niet voldoende dat elk cluster individueel compliant is; de auditor wil vaak ook een overzicht per cluster, met een duidelijke verklaring voor eventuele verschillen (bijvoorbeeld: een ontwikkelcluster met minder strikte policy's, met documentatie waarom dat aanvaardbaar is gezien de aard van de data die daar wordt verwerkt).

Hoofdstuk 10 — Netwerksegmentatie en NetworkPolicies

Netwerksegmentatie is een kernonderdeel van de Security-criteria (CC6.6/CC6.7): het beperken van lateral movement wanneer een aanvaller toch toegang krijgt tot één onderdeel van het systeem.

Alle drie de platformen ondersteunen Kubernetes NetworkPolicies, maar de mate van standaard-restrictiviteit verschilt. De aanbevolen aanpak, ongeacht platform:

1. Begin met een default-deny NetworkPolicy per namespace: al het verkeer wordt geblokkeerd tenzij expliciet toegestaan.
2. Voeg per applicatie gerichte policies toe die alleen het strikt noodzakelijke verkeer toestaan (bijvoorbeeld: frontend mag praten met backend op poort 8080, niet met de database rechtstreeks).
3. Segmenteer gevoelige workloads (zoals databases met persoonsgegevens) in een aparte namespace met extra restricties.
4. Documenteer de netwerktopologie — een auditor vraagt vaak expliciet om een netwerkdiagram als onderbouwing van deze controle.

Voorbeeld: default-deny plus expliciet toegestaan verkeer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: backend-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: frontend
      ports:
        - protocol: TCP
          port: 8080

Deze twee policy's samen illustreren het least-privilege-principe: zonder de tweede policy zou de eerste alle verkeer blokkeren, inclusief legitiem verkeer — precies de bedoeling, tot expliciet anders gedefinieerd.

Hoofdstuk 11 — Versleuteling: at rest en in transit

Encryption at rest

Data die is opgeslagen (etcd, persistent volumes, backups) moet versleuteld zijn. Kubernetes ondersteunt etcd-encryptie via een EncryptionConfiguration, maar dit staat niet altijd standaard aan. Controleer expliciet:

• Is etcd-encryptie geactiveerd voor Secrets en andere gevoelige resources?
• Zijn onderliggende persistent volumes versleuteld op storage-niveau (bijvoorbeeld via de cloud-provider of storage-laag)?
• Zijn back-ups eveneens versleuteld, niet alleen de actieve data?

Encryption in transit

Verkeer tussen componenten (API server naar kubelet, pod-naar-pod, en extern binnenkomend verkeer) moet versleuteld zijn. Overweeg een service mesh (zoals Istio of OpenShift Service Mesh) voor automatische mTLS tussen services, wat zowel de beveiliging verbetert als het bewijs van encryptie-in-transit sterk vereenvoudigt — mTLS-certificaten en hun rotatiebeleid zijn direct auditeerbaar bewijs.

Voorbeeld: etcd-encryptieconfiguratie

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-versleutelingssleutel>
      - identity: {}

De volgorde van providers is belangrijk: nieuwe objecten worden versleuteld met de eerste provider in de lijst (aescbc), terwijl identity als laatste zorgt dat reeds bestaande, onversleutelde objecten nog gelezen kunnen worden totdat ze opnieuw zijn opgeslagen. Vergeet niet om na activering een herschrijfactie uit te voeren op bestaande Secrets, anders blijven oudere objecten alsnog onversleuteld op schijf staan.

Hoofdstuk 12 — Secrets management en sleutelbeheer

Kubernetes Secrets zijn standaard slechts base64-gecodeerd, niet versleuteld — een veelvoorkomend misverstand dat bij audits regelmatig naar boven komt. Voor SOC 2-doeleinden is een externe secrets manager (zoals OpenBao/Vault) vrijwel altijd noodzakelijk voor gevoelige productiegeheimen.

• Centrale opslag — wachtwoorden, API-sleutels en certificaten horen in een toegewijde secrets manager, niet los in manifests of environment-variabelen in Git.
• Dynamische secrets — waar mogelijk, gebruik tijdelijke, automatisch verlopende credentials (bijvoorbeeld dynamische databasewachtwoorden) in plaats van statische, langlevende geheimen.
• Rotatiebeleid — een gedocumenteerd en aantoonbaar uitgevoerd rotatieschema voor sleutels en wachtwoorden is een expliciete controle binnen CC6.1.
• Toegang tot secrets — net als bij reguliere RBAC geldt least privilege: alleen de services en personen die een geheim daadwerkelijk nodig hebben, krijgen er toegang toe.

Hoofdstuk 13 — Audit-logging en centrale logaggregatie

Auditlogging is misschien wel het meest directe technische bewijs dat een auditor nodig heeft: wie deed wat, wanneer, en met welk resultaat. Alle drie de platformen ondersteunen Kubernetes API-audit-logging, maar de mate van kant-en-klare aggregatie en retentie verschilt.

• Wat loggen — configureer op zijn minst: authenticatiepogingen (geslaagd en mislukt), wijzigingen aan RBAC-objecten, wijzigingen aan Secrets en ConfigMaps, en het aanmaken/verwijderen van workloads in productienamespaces.
• Waar bewaren — logs horen buiten het cluster zelf te worden opgeslagen (een centrale logaggregatie-oplossing), zodat een aanvaller die het cluster compromitteert niet ook het bewijs daarvan kan wissen.
• Retentieperiode — stem de retentie af op de audit-observatieperiode (voor Type II doorgaans minimaal de volledige observatieperiode plus enige marge).
• Alerting op afwijkingen — logging zonder monitoring is beperkt waardevol; koppel kritieke gebeurtenissen (bijvoorbeeld een nieuwe ClusterRoleBinding met cluster-admin) aan actieve alertering.

Voorbeeld: een gerichte audit-policy

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  - level: Metadata
    omitStages:
      - "RequestReceived"

Het niveau RequestResponse legt zowel het verzoek als het antwoord volledig vast — nuttig voor RBAC-wijzigingen waar de volledige inhoud relevant is voor een audit. Voor Secrets kiezen we bewust Metadata: wél vastleggen dát een Secret is gewijzigd en door wie, maar niet de inhoud zelf in de audit-log opnemen, om te voorkomen dat gevoelige waarden alsnog in logs terechtkomen.

Hoofdstuk 14 — Container- en supply-chain-security

SOC 2 kijkt niet alleen naar de draaiende omgeving, maar ook naar hoe software daarin terechtkomt. Supply-chain-security — het beveiligen van de hele keten van broncode tot draaiend Increment — wordt een steeds prominenter onderdeel van audits.

• Image-scanning — elke container-image wordt gescand op bekende kwetsbaarheden (CVE's) vóórdat deze naar productie mag. OpenShift's interne registry en NKP bieden dit kant-en-klaar; bij vanilla Kubernetes is een externe registry met scanning (zoals Harbor met Trivy) nodig.
• Software Bill of Materials (SBOM) — een gestructureerde lijst van alle componenten in een image, essentieel om snel te kunnen bepalen of een nieuw ontdekte kwetsbaarheid relevant is voor je omgeving.
• Ondertekenen van images — met tools als Cosign/Sigstore kan een image cryptografisch worden ondertekend, zodat admission control kan verifiëren dat een image daadwerkelijk uit de eigen, vertrouwde pipeline komt.
• Admission control — een policy-engine (OPA/Gatekeeper, Kyverno, of OpenShift's ingebouwde admission-mechanismen) weigert images die niet aan het beleid voldoen (bijvoorbeeld: niet ondertekend, of met kritieke kwetsbaarheden).

Hoofdstuk 15 — Policy as code: OPA/Gatekeeper, Kyverno en Compliance Operator

Handmatige controle van configuratie schaalt niet, zeker niet over meerdere clusters en teams. Policy as code maakt het mogelijk organisatiebeleid te definiëren als machineleesbare regels die automatisch worden afgedwongen én die zelf weer bewijsmateriaal opleveren.

• Open Policy Agent (OPA) / Gatekeeper — een cloud-native policy-engine waarin beleid wordt geschreven in de taal Rego en wordt toegepast als Kubernetes admission control.
• Kyverno — een alternatief dat policy's definieert in native Kubernetes YAML in plaats van een aparte taal, vaak toegankelijker voor teams zonder Rego-ervaring.
• OpenShift Compliance Operator — specifiek gericht op het toetsen tegen erkende benchmarks (zie hoofdstuk 7).

Voorbeelden van beleid dat vrijwel elke SOC 2-scope raakt: verplicht resource-limieten op elke container, verbied privileged containers, verplicht een specifieke label-set voor kostenverantwoording en eigenaarschap, en verbied het gebruik van de latest-tag voor productie-images (om reproduceerbaarheid te waarborgen).

Voorbeeld: Gatekeeper-constraint tegen privileged containers

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: no-privileged-containers
spec:
  enforcementAction: deny
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    excludedNamespaces:
      - kube-system

Merk op dat systeemnamespaces zoals kube-system bewust worden uitgesloten — dit voorkomt dat het beleid platformcomponenten breekt die legitiem verhoogde rechten nodig hebben, terwijl reguliere applicatienamespaces wel worden afgedwongen.

Hoofdstuk 16 — Kwetsbaarhedenbeheer en patchmanagement

CC7.1 (systeembewerking) vereist dat een organisatie kwetsbaarheden identificeert en tijdig verhelpt. Voor een Kubernetes-gebaseerde omgeving speelt dit op meerdere niveaus tegelijk.

• Platformniveau — patches voor Kubernetes/OpenShift/NKP zelf, inclusief de onderliggende node-besturingssystemen.
• Image-niveau — kwetsbaarheden in basis-images en dependencies binnen container-images (zie hoofdstuk 14).
• Configuratieniveau — misconfiguraties die door scanners (zoals de Compliance Operator of kube-bench) worden gesignaleerd.

Voor elk niveau is een gedocumenteerd, aantoonbaar nagekomen SLA nodig: bijvoorbeeld "kritieke kwetsbaarheden binnen 48 uur patchen, hoge kwetsbaarheden binnen 14 dagen". Auditors toetsen niet alleen of dit beleid bestaat, maar of de daadwerkelijke doorlooptijden (zichtbaar in ticketsystemen of scanhistorie) hieraan voldoen.

Hoofdstuk 17 — Change management en GitOps als controlemechanisme

CC8.1 (wijzigingsbeheer) vereist dat wijzigingen aan systemen op een gecontroleerde, geautoriseerde manier plaatsvinden. GitOps — waarbij de gewenste staat van infrastructuur in Git wordt beschreven en automatisch wordt toegepast — is een uitstekende, natuurlijke match met deze eis.

Waarom GitOps zich zo goed leent voor SOC 2-bewijs:

• Herleidbaarheid — elke wijziging staat in de Git-historie: wie, wat, wanneer, en (via de pull request-beschrijving) waarom.
• Vier-ogen-principe — een verplichte code review vóór merge zorgt voor een ingebouwd goedkeuringsmechanisme, direct auditeerbaar via de pull-request-geschiedenis.
• Geautomatiseerde controles — CI/CD-pipelines kunnen policy-checks, tests en scans afdwingen vóórdat een wijziging het cluster bereikt.
• Reproduceerbaarheid — bij een incident kan exact worden vastgesteld welke configuratie op welk moment actief was, en indien nodig teruggedraaid naar een eerdere, bekende-goede staat.

Voorbeeld: een Argo CD Application met verplichte goedkeuring

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: productie-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://git.voorbeeld.nl/platform/productie-app.git
    targetRevision: main
    path: manifests/productie
  destination:
    server: https://kubernetes.default.svc
    namespace: productie-app
  syncPolicy:
    automated:
      prune: false
      selfHeal: true

selfHeal: true zorgt dat handmatige, ongeautoriseerde wijzigingen in het cluster automatisch worden teruggedraaid naar de staat in Git — een directe, technische handhaving van het change-management-principe. prune: false is bewust conservatief: verwijderde resources uit Git worden niet automatisch verwijderd uit het cluster zonder expliciete actie, om onbedoeld dataverlies te voorkomen.

Hoofdstuk 18 — Back-up, disaster recovery en business continuity

Voor organisaties die Availability als Trust Services Criterion meenemen, is een aantoonbaar geteste disaster-recovery-strategie essentieel — niet alleen het bestaan van back-ups, maar bewijs dat herstel daadwerkelijk werkt.

• Wat back-uppen — etcd (de volledige clusterstaat), persistent volumes met applicatiedata, en configuratie die niet via GitOps wordt beheerd.
• Waar bewaren — back-ups horen buiten het cluster en idealiter in een andere faalzone/regio te staan, versleuteld (zie hoofdstuk 11).
• Restore-testen — een back-up die nooit is teruggezet, is geen bewezen back-up. Plan periodieke, gedocumenteerde restore-oefeningen, inclusief het meten van de daadwerkelijke Recovery Time Objective (RTO) en Recovery Point Objective (RPO).
• Multi-cluster/multi-regio strategie — voor kritieke workloads kan actieve replicatie naar een tweede cluster de RTO drastisch verkorten ten opzichte van alleen back-up-restore.

Voorbeeld: een geautomatiseerd back-upschema

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: dagelijkse-backup
  namespace: velero
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces:
      - productie-app
      - productie-data
    storageLocation: versleutelde-s3-backup
    ttl: 720h0m0s

De ttl (720 uur = 30 dagen) bepaalt hoe lang een back-up bewaard blijft — stem dit af op zowel operationele hersteleisen als de audit-observatieperiode. Test met enige regelmaat een daadwerkelijke restore vanuit deze back-ups naar een geïsoleerde omgeving, niet alleen een technische validatie dat het back-upproces "geslaagd" rapporteert.

Hoofdstuk 19 — Monitoring, alerting en incident response

Zelfs de best ingerichte preventieve controles voorkomen niet elk incident. CC7.3-7.5 vereisen een gestructureerde aanpak van detectie, respons en herstel.

Monitoring en alerting

Monitor zowel infrastructuurmetrics (CPU, geheugen, node-status) als beveiligingsrelevante signalen (ongebruikelijke API-aanroepen, nieuwe privileged containers, afwijkende netwerkverbindingen). Tools als Prometheus voor metrics en Falco voor runtime-detectie vullen elkaar hierbij aan.

Incident response

Een gedocumenteerd incident-response-plan moet minstens beschrijven: hoe een incident wordt gedetecteerd en opgeschaald, wie verantwoordelijk is voor besluitvorming, hoe communicatie (intern en naar klanten) verloopt, en hoe een post-mortem wordt vastgelegd en opgevolgd.

Oefenen

Een ongeoefend draaiboek faalt vaak precies op het moment dat het nodig is. Periodieke, gestructureerde oefeningen ("game days") — zowel aangekondigd als onaangekondigd — bouwen aantoonbare paraatheid op, en de verslagen daarvan vormen weer bruikbaar auditbewijs.

Voorbeeld: een Falco-detectieregel

- rule: Onverwachte shell in container
  desc: Detecteert het starten van een interactieve shell binnen een productiecontainer
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh) and
    k8s.ns.name = "productie-app"
  output: >
    Onverwachte shell gestart (gebruiker=%user.name container=%container.name
    commando=%proc.cmdline namespace=%k8s.ns.name)
  priority: WARNING

Voorbeeld: een Prometheus-alertregel

groups:
  - name: rbac-bewaking
    rules:
      - alert: NieuweClusterAdminBinding
        expr: increase(apiserver_audit_event_total{verb="create",objectRef_resource="clusterrolebindings"}[5m]) > 0
        for: 0m
        labels:
          severity: warning
        annotations:
          summary: "Nieuwe ClusterRoleBinding aangemaakt"
          description: "Controleer onmiddellijk of deze wijziging geautoriseerd is."

Hoofdstuk 20 — Continu bewijs verzamelen: van jaarlijkse audit naar continuous compliance

De grootste valkuil bij SOC 2 Type II is het verzamelen van bewijsmateriaal als eenmalige exercitie vlak vóór de audit. Omdat een Type II-rapport de hele observatieperiode beoordeelt, moet bewijs continu en automatisch worden opgebouwd.

Een praktische aanpak:

1. Vertaal elk relevant Trust Services Criterion naar een concrete, geautomatiseerde controle (policy as code, een scanschema, of een periodiek rapport).
2. Verzamel de output van die controles centraal en gestructureerd — niet verspreid over losse screenshots en spreadsheets.
3. Bouw een dashboard dat op elk moment laat zien: welke controles actief zijn, wanneer ze voor het laatst zijn uitgevoerd, en of er openstaande afwijkingen zijn.
4. Zorg dat een auditor met beperkte, gerichte steekproeftoegang zelf bewijs kan raadplegen, in plaats van dat het platformteam alles handmatig moet aanleveren.

Hoofdstuk 20a — Derde partijen en leveranciersbeheer

CC9 (risicobeperking) vereist expliciet aandacht voor risico's die voortkomen uit derde partijen. Een Kubernetes-gebaseerd platform bestaat zelden uit alleen eigen code: Helm-charts van externe leveranciers, community-operators, basis-images van derden en de onderliggende clouddienst of hardwareleverancier maken allemaal deel uit van de vertrouwensketen.

Leveranciersbeoordeling

Voor elke belangrijke externe afhankelijkheid — de Kubernetes-distributie zelf, kritieke operators, of een clouddienst — is een gedocumenteerde beoordeling nodig: heeft deze leverancier zelf een actueel SOC 2- of ISO 27001-rapport, wat is hun patchbeleid, en hoe worden kwetsbaarheden gecommuniceerd?

Software-leveranciers binnen het cluster

Community-operators en Helm-charts van derden verdienen extra aandacht: controleer de herkomst (officieel gepubliceerd door de leverancier, of een niet-geverifieerde fork), of images ondertekend zijn, en of het onderhoudsteam actief kwetsbaarheden patcht. Een operator die al twee jaar niet is bijgewerkt, is een reëel risico, ongeacht hoe nuttig de functionaliteit is.

Hoofdstuk 20b — Kostenafwegingen tussen platforms in een compliance-context

De keuze tussen OpenShift, vanilla Kubernetes en NKP heeft niet alleen technische, maar ook financiële implicaties voor een compliance-traject — vaak onderschat totdat de daadwerkelijke inspanning voor een audit zichtbaar wordt.

Een organisatie die kiest voor vanilla Kubernetes vanwege lagere licentiekosten, moet die besparing afzetten tegen de extra ontwikkeltijd die nodig is om een vergelijkbaar compliance-niveau te bereiken als OpenShift of NKP kant-en-klaar bieden. Voor kleinere teams zonder toegewijde platformcapaciteit is dit vaak een doorslaggevende overweging; voor grotere organisaties met specialistische Kubernetes-teams kan de flexibiliteit en het ontbreken van licentiekosten juist opwegen tegen de extra bouwinspanning.

Hoofdstuk 21 — Praktijkcasus: voorbereiding op een SOC 2 Type II-audit

Ter illustratie: "Voorbeeld Cloud B.V." draait haar SaaS-product op een OpenShift-cluster en bereidt zich voor op haar eerste SOC 2 Type II-audit, met een observatieperiode van zes maanden.

Maand 1-2: nulmeting en inrichting

Het platformteam voert een gap-analyse uit tegen de Common Criteria en ontdekt drie belangrijke hiaten: geen centrale logaggregatie, te ruime RBAC-rollen (acht mensen met cluster-admin), en geen gedocumenteerd patchbeleid. Alle drie worden binnen twee maanden hersteld: logaggregatie wordt ingericht, RBAC wordt teruggebracht tot twee mensen met clusterbrede rechten plus namespace-specifieke rollen voor de rest, en een patch-SLA wordt gedocumenteerd en in het ticketsysteem verankerd.

Maand 3-4: automatiseren van bewijs

De Compliance Operator wordt ingeschakeld met een wekelijks scanschema, Gatekeeper-policy's worden ingevoerd (eerst in audit-modus, na twee weken op enforce), en een centraal dashboard toont voortaan de status van alle controles.

Maand 5-6: oefenen en verfijnen

Een restore-oefening onthult dat de daadwerkelijke RTO (6 uur) hoger ligt dan het gedocumenteerde doel (4 uur); het team past het back-upschema aan en test opnieuw, met een geslaagd resultaat van 3,5 uur. Een aangekondigde incident-response-oefening ("game day") wordt uitgevoerd en het post-mortem-verslag wordt toegevoegd aan het bewijsdossier.

Aan het einde van de observatieperiode beschikt het team over zes maanden aan consistente, geautomatiseerd verzamelde logs, scanresultaten en wijzigingshistorie — precies het soort continu bewijs waar een Type II-auditor naar op zoek is, in plaats van een gehaaste reconstructie achteraf.

Hoofdstuk 22 — Conclusie en aanbevolen vervolgstappen

SOC 2-compliance op een Kubernetes-gebaseerd platform is geen kwestie van het juiste product kopen, maar van het bewust inrichten en consistent uitvoeren van een beperkte set kerncontroles: toegangsbeheer, netwerksegmentatie, versleuteling, secrets-beheer, auditlogging, supply-chain-beveiliging, wijzigingsbeheer, en continuïteitsplanning.

1. OpenShift en NKP bieden meer kant-en-klare bouwstenen dan vanilla Kubernetes, maar geen van de drie is "gratis compliant" — elk vereist bewuste configuratie.
2. Type II-audits vereisen continu bewijs; bouw daarom vroeg een automatisch evidence-verzamelingsproces op, niet pas vlak vóór de audit.
3. GitOps en policy as code zijn niet alleen operationeel waardevol, maar leveren als bijproduct precies het soort herleidbaar bewijs dat auditors zoeken.
4. Test preventieve én reactieve controles daadwerkelijk (restore-oefeningen, incident-response-game-days) — ongeteste plannen zijn geen bewezen controles.
5. Een SOC 2-rapport is geen eindpunt maar een herhalend proces; de volgende Type II-periode begint feitelijk zodra de vorige is afgerond.

De aanbevolen vervolgstap voor elk team dat dit boek als uitgangspunt gebruikt: voer eerst een gap-analyse uit tegen de Common Criteria op het eigen platform, en prioriteer daarna de hiaten op basis van risico — niet op basis van wat toevallig het makkelijkst is om als eerste op te lossen.

Bijlage A — Mapping: Trust Services Criteria naar technische controls

Bijlage B — Glossarium

Bijlage C — Auditvoorbereiding-checklist

C.1 Toegang en identiteit

• Centrale identity-provider gekoppeld aan alle clusters?
• Geen overmatig gebruik van cluster-admin/cluster-brede rechten?
• Periodieke toegangsreview gedocumenteerd?

C.2 Netwerk en versleuteling

• Default-deny NetworkPolicy per namespace?
• etcd-encryptie geactiveerd?
• TLS/mTLS afgedwongen voor extern en intern verkeer?

C.3 Supply chain

• Alle productie-images gescand op kwetsbaarheden?
• Ondertekening en verificatie van images ingericht?
• SBOM beschikbaar per image?

C.4 Wijzigingsbeheer

• Alle productiewijzigingen via GitOps/versiebeheer?
• Verplichte code review vóór merge?
• Geen ongedocumenteerde handmatige wijzigingen in productie?

C.5 Continuïteit en respons

• Back-ups getest met een recente, gedocumenteerde restore-oefening?
• RTO/RPO gedefinieerd en gehaald?
• Incident-response-plan geoefend binnen het afgelopen jaar?

C.6 Bewijsmateriaal

• Centrale logaggregatie met voldoende retentie voor de observatieperiode?
• Geautomatiseerde compliance-scans met bewaarde historie?
• Dashboard of overzicht waarmee een auditor gericht bewijs kan raadplegen?

Bijlage D — Aanbevolen bronnen en tooling

• AICPA Trust Services Criteria — de officiële, volledige omschrijving van alle criteria.
• OpenShift Compliance Operator-documentatie — voor CIS-, NIST- en PCI-profielen.
• CIS Benchmarks voor Kubernetes — leidend raamwerk voor baseline-hardening.
• kube-bench — open source CIS Benchmark-scanner voor vanilla Kubernetes.
• Open Policy Agent / Gatekeeper en Kyverno-documentatie — voor policy as code.
• Sigstore/Cosign — voor het ondertekenen en verifiëren van container-images.
• Nutanix Kubernetes Platform (NKP)-documentatie — voor platformspecifieke compliance-features.

Dit boek is bedoeld als technisch-architecturale gids, niet als vervanging voor begeleiding door een gekwalificeerde auditor of compliance-specialist. Betrek bij een daadwerkelijk SOC 2-traject altijd een ervaren auditor of compliancebureau om de exacte scope en interpretatie van de criteria voor de eigen organisatie te bepalen.