Compliance evidence from the cluster itself: NCA ECC on Kubernetes

A regulated organisation must show its assessor, control by control, how its systems meet the regulator’s requirements. For a Kubernetes platform that is harder than it sounds. Workloads are deployed, scaled and replaced many times a day, so the evidence an assessment asks for, such as which images run, whether they carry known vulnerabilities, who may do what, whether workloads are separated and whether logs are kept, describes the cluster only as it was on the day it was gathered. It is usually gathered by hand, before each assessment, in screenshots and spreadsheets.

The Compliance and Assurance Convoy for Bahriya Tersane takes a different approach: the cluster produces its own evidence, every day, against the regime’s own control numbers. This article describes how it does so for the first regime it covers, the Saudi National Cybersecurity Authority’s Essential Cybersecurity Controls, ECC-2:2024, which which is available today in the experimental Convoy. The images below are taken on a test cluster with sample workloads.

Four sources of evidence

The convoy installs into the cluster beside the Tersane kyverno and trivy-operator charts and reads four sources.

Admission policies, in two layers. Every control the Kubernetes API server can decide by itself is shipped as a built-in ValidatingAdmissionPolicy: images only from authorised registries, no service account token mounted by default, resource limits set, environment and data classification labels on every namespace, and similar. This layer needs no policy engine and holds if Kyverno is removed. Kyverno adds only what the API server cannot do: image signature verification, a generated default-deny NetworkPolicy per namespace, and policy reports for the built-in layer. A newly installed convoy refuses nothing; every policy warns and records until the organisation sets that control to deny.

The cluster’s scanners. trivy-operator scans each workload’s images for known vulnerabilities and audits each workload’s configuration and each role’s permissions. The convoy computes every result itself from trivy-operator’s raw reports, so a check that has not yet run is reported as not evaluated, never as passed.

Platform facts. From the Bahriya Kubernetes Engine 2.3.0, the platform declares the controls it provides, among them audit logging, encryption of Secrets at rest, Pod Security defaults, control-plane and kubelet settings, a trusted time source and a host firewall. The convoy reports each one, switched on or off, as provided by the platform. On earlier BKE versions and on another distribution, those requirements are reported as not evidenced by the cluster, and the report asks for the organisation’s own evidence instead.

Node facts. A short, read-only Job on each node records the time source, the kubelet’s configuration in effect and the permissions of named files. The convoy reads the cluster’s configuration and never changes it.

The report

Once a day, one run per regime joins every result to the regime’s requirements and writes a report. It lists every requirement with exactly one result: pass, fail, incomplete where some checks could not yet be judged, recorded where evidence is kept for review without a verdict, or customer evidence for an organisational requirement. Every technical result names the checks that produced it.

Before the requirements, the report lists what to fix first: every object that fails a check, grouped by namespace and ordered by its most severe finding, with what is wrong, how to fix it and the requirements it affects. The team that owns a namespace reads its own section and starts at the top.

The same report is rendered as PDF inside the cluster, with no browser and nothing fetched, and as OSCAL 1.1 assessment results, one finding per requirement, which governance, risk and compliance tools can import. Every file is listed with its SHA-256 digest in a manifest, signed with the organisation’s key when one is provided. The files stay on a volume in the convoy’s namespace; they can also be delivered to the organisation’s own SMTP server over TLS, or to its own S3-compatible storage. Nothing is sent to Mamluk.

NCA ECC-2:2024, requirement by requirement

The convoy holds all 176 requirements of ECC-2:2024, across its four domains and 28 subdomains, under NCA’s own identifiers, each with a short description written by Mamluk; NCA’s text is not reproduced. Each requirement is classed by how its evidence is obtained:

Class	Requirements	How it is evidenced
Enforced	7	An admission policy flags, and once chosen blocks, what the requirement forbids
Checked	14	The convoy observes the requirement in the cluster
Platform	13	The platform provides the control and declares it
Customer evidence	142	Organisational; listed for the organisation to evidence

Thirty-three of the 34 technical requirements are partly technical: the cluster evidences its own part, and the report also asks for the organisation’s evidence of the rest. Where a regime sets a threshold, the convoy uses the regime’s value; ECC’s twelve months of event log retention (2-12-3-5) is the value the audit log rotation check is judged against.

One mapping, keyed to NIST

Every check is mapped once to the NIST SP 800-53 Rev. 5 controls it evidences: in the first release, 40 NIST controls, evidenced by 51 checks. Each regime’s requirements are mapped to the same NIST controls, so a requirement’s result is drawn from the checks of the controls it maps to, and a new regime is added as data rather than as new policies or scanners. An organisation that answers to two regulators, such as a bank in Saudi Arabia that must meet both NCA ECC and SAMA’s framework, is scanned once and reported against each regime in its own numbering once SAMA’s framework is added.

The regimes that follow NCA ECC are expected in the first quarter of 2027: the Qatar Central Bank’s requirements for banks, the SAMA Cyber Security Framework, and, for the United Arab Emirates, the UAE Information Assurance Standard with the Central Bank of the UAE’s requirements for banks. Bahrain, Kuwait, Qatar’s National Information Assurance Standard and SAMA’s cyber resilience requirements follow later in 2027. Each has its own page under the convoy. The UAE standard maps its controls to NIST itself, and the convoy takes that mapping as published; for QCB and SAMA, which publish no crosswalk to NIST, the mapping is Mamluk’s own.

Your registries, not a cloud provider’s list

One of the checks the scanner ships with, AVD-KSV-0125, decides whether an image comes from a trusted registry by comparing it with a fixed list: the registries of Microsoft Azure, Amazon Elastic Container Registry and Google. All three providers are based in the United States. Any other registry is reported as untrusted, including a registry in the organisation’s own data centre, a registry in a national or in-country cloud, and the registry from which Bahriya Tersane’s own images are served.

For an organisation whose regulator or policy requires its systems and data to remain in the country, that result measures whether an image comes from one of three providers, not whether it comes from a source the organisation trusts. The list cannot be replaced in trivy-operator without losing its other checks: measured on a test cluster, supplying one removed every built-in configuration check from each report, 55 checks to none.

The convoy therefore does not use that check. You name your authorised registries; the convoy warns about, or once you choose refuses, an image from any other registry, and its report evidences the result for every workload. The convoy’s documentation lists each scanner check it does not use, with the reason, so that the choice can be reviewed by your assessor.

What the convoy does not do

The convoy maps a regime’s technical controls to the cluster and records the evidence for them. The mapping is Mamluk’s. The convoy does not make an organisation compliant and does not certify compliance. The organisational requirements remain the organisation’s to evidence, and compliance is determined by its assessor. The report says so on its first page.

Price, and how to start

The Compliance and Assurance Convoy requires the Bahriya Tersane core licence and Kubernetes 1.36 or later. It runs on the Bahriya Kubernetes Engine 2.2.0 or later, or on any conformant Kubernetes distribution at that version; before BKE 2.3.0 and on another distribution, the requirements the platform provides are reported for the organisation to evidence. It is licensed at USD 24,000 per regulatory regime, per organisation, per year, with no base fee. The convoy is experimental, and NCA ECC is available today; its installation is described in the documentation. To discuss the regimes your organisation must meet, contact Mamluk.