Compliance and Regulatory Mapping¶
How CloudTaser helps EU enterprises meet regulatory requirements for data protection, operational resilience, and information security when running workloads on US cloud providers.
GDPR Article 32 -- Security of Processing¶
Article 32 requires "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk, including encryption and the ability to ensure ongoing confidentiality of processing systems.
| Requirement | CloudTaser Measure |
|---|---|
| Encryption of personal data | Secrets (including encryption keys, database credentials, API tokens) are fetched from an EU-hosted vault over TLS and held only in process memory. They never transit any US-controlled storage layer |
| Ongoing confidentiality | The wrapper uses memfd_secret (kernel 5.14+) to hide secret pages from the kernel direct map. Even a root-level attacker or the cloud provider cannot read them from /proc, /dev/mem, or kernel modules |
| Pseudonymisation | CloudTaser protects the keys used for pseudonymisation. If keys are stored in EU vault and injected via CloudTaser, they are inaccessible to the cloud provider |
| Regular testing and evaluation | cloudtaser audit generates compliance reports showing protected vs. unprotected workloads, eBPF enforcement coverage, and protection scores. Run regularly for ongoing assurance |
GDPR Articles 44-49 -- International Transfers (Schrems II)¶
After the Schrems II ruling (C-311/18), transfers of personal data to the US require "supplementary measures" that ensure the data is protected against US government access. CloudTaser provides technical supplementary measures.
Supplementary Measures Mapping¶
| EDPB Supplementary Measure | CloudTaser Implementation |
|---|---|
| Measure 1: Encryption in transit and at rest with keys held in the EU | Secrets are fetched from an EU-hosted vault over mTLS. In the workload, secrets exist only in process memory (not at rest). The vault encryption keys never leave EU jurisdiction |
| Measure 2: Pseudonymised data processing | CloudTaser protects pseudonymisation keys in process memory, ensuring the cloud provider cannot re-identify pseudonymised data |
| Measure 4: Encryption by the data exporter with sole key control | The EU data controller retains sole control of vault keys. The US cloud provider operates the infrastructure but has no access to the keys (technical, not contractual, guarantee) |
| Measure 9: Processing only in the EEA | Vault (the key store) is hosted exclusively in the EU. Processing occurs on US cloud infrastructure, but secrets are cryptographically protected from the provider |
How CloudTaser Addresses US Government Access¶
The threat model assumes the US cloud provider (or a US government agency via CLOUD Act / FISA 702) has root access to the Kubernetes node. CloudTaser's defense layers ensure that even with root access:
memfd_secret(kernel 5.14+) removes secret pages from the kernel direct map. Kernel modules,/dev/mem, and hypervisor access cannot read them- eBPF enforcement blocks
ptrace,/proc/pid/memreads,process_vm_readv, and other memory access syscalls targeting protected processes - No persistence -- secrets never touch etcd, Kubernetes Secrets, disk, swap, or core dumps
Technical vs contractual measures
Schrems II requires supplementary measures that go beyond contractual guarantees. CloudTaser provides technical enforcement -- the cloud provider is physically unable to access the secrets, regardless of any legal compulsion.
NIS2 Directive¶
The NIS2 Directive (Directive (EU) 2022/2555) requires essential and important entities to implement cybersecurity risk management measures and report significant incidents.
Article 21 -- Cybersecurity Risk Management Measures¶
| NIS2 Requirement | CloudTaser Measure |
|---|---|
| (a) Policies on risk analysis and information system security | cloudtaser audit provides a security posture report. Protection scores quantify the level of runtime protection per workload |
| (b) Incident handling | The eBPF agent detects and blocks exfiltration attempts in real time (e.g., ptrace, /proc reads, unauthorized write/sendto). Events are logged for incident response |
| (d) Supply chain security | CloudTaser eliminates the risk of secrets leaking through the cloud provider supply chain. The provider never holds the keys |
| (e) Security in network and information systems acquisition | cloudtaser validate and cloudtaser discover assess the security posture before and after deployment |
| (h) Policies and procedures for cryptography and encryption | All secrets are encrypted in transit (TLS) and protected in memory (memfd_secret, mlock, eBPF). CloudTaser enforces a consistent cryptographic protection model across all workloads |
| (j) Use of multi-factor authentication and secured communication | Vault authentication uses Kubernetes ServiceAccount tokens (bound to pod identity). The wrapper strips authentication tokens from the child process environment |
Incident Detection Events¶
CloudTaser's eBPF agent generates the following security events, which support NIS2 incident detection requirements:
| Event | Description |
|---|---|
SECRET_LEAK |
Process attempted to write secret data to a file or network socket |
PROCMEM_READ |
External process attempted to read /proc/pid/mem of a protected process |
ENVIRON_READ |
External process attempted to read /proc/pid/environ |
PTRACE_DENIED |
ptrace attach/seize attempt on a protected process |
MODULE_LOAD |
Kernel module loaded (potential privilege escalation) |
BPF_LOAD |
New eBPF program loaded (potential monitoring bypass) |
DORA -- Digital Operational Resilience Act¶
DORA (Regulation (EU) 2022/2554) applies to financial entities and requires ICT risk management, incident reporting, digital operational resilience testing, and third-party risk management.
Chapter II -- ICT Risk Management¶
| DORA Article | CloudTaser Measure |
|---|---|
| Art. 6 -- ICT risk management framework | CloudTaser reduces the risk surface of secret management. Protection scores provide quantifiable risk metrics. cloudtaser audit produces reports suitable for ICT risk assessments |
| Art. 7 -- ICT systems, protocols and tools | CloudTaser operates at the kernel level (eBPF, memfd_secret) and application level (fork+exec wrapper). It does not depend on the cloud provider's security controls |
| Art. 8 -- Identification of ICT risks | cloudtaser discover identifies workloads that reference Kubernetes Secrets (which are stored in etcd, accessible to the cloud provider). Each represents a data sovereignty risk |
| Art. 9 -- Protection and prevention | The eBPF agent proactively blocks exfiltration attempts. The wrapper prevents secrets from reaching any US-controlled storage. These are preventive controls |
| Art. 10 -- Detection | eBPF tracepoints and kprobes detect anomalous access patterns in real time. Events are generated for SIEM integration |
| Art. 11 -- Response and recovery | On detection of a policy violation, the eBPF agent can terminate the offending process (reactive kill). The wrapper handles graceful restart via configurable rotation strategies |
Chapter V -- Third-Party ICT Service Provider Risk¶
| DORA Requirement | CloudTaser Measure |
|---|---|
| Art. 28 -- Third-party risk management | CloudTaser's technical controls mean the cloud provider (a third-party ICT service provider) cannot access secrets, regardless of contractual terms. This reduces residual risk to near-zero for secret data |
| Art. 30 -- Key contractual provisions | CloudTaser supplements contractual provisions with technical enforcement. Even if the provider is compelled by US law to provide access, the technical controls prevent secret extraction |
ISO 27001 Controls Mapping¶
CloudTaser supports implementation of the following ISO 27001:2022 Annex A controls:
| Control | Title | CloudTaser Contribution |
|---|---|---|
| A.5.31 | Legal, statutory, regulatory and contractual requirements | Provides technical supplementary measures for Schrems II compliance |
| A.8.2 | Privileged access rights | eBPF blocks privileged operations (ptrace, module loading) on protected processes |
| A.8.5 | Secure authentication | Vault Kubernetes auth binds authentication to pod identity (ServiceAccount token) |
| A.8.7 | Protection against malware | eBPF blocks code injection via ptrace and process memory write |
| A.8.9 | Configuration management | cloudtaser validate verifies correct configuration. cloudtaser audit detects drift |
| A.8.10 | Information deletion | Secrets are never written to persistent storage. They exist only in volatile process memory and are destroyed when the process exits |
| A.8.11 | Data masking | CloudTaser can be used to protect data masking keys in process memory |
| A.8.12 | Data leakage prevention | eBPF agent blocks secret exfiltration via write, sendto, sendfile, splice, io_uring |
| A.8.20 | Networks security | Network policies restrict communication to the vault endpoint. cloudtaser netpol generates policies automatically |
| A.8.24 | Use of cryptography | All vault communication is over TLS. Secrets are protected in memory using kernel-level primitives (memfd_secret, mlock) |
| A.8.25 | Secure development lifecycle | CloudTaser integrates into the deployment pipeline. cloudtaser discover scans for insecure secret references before production deployment |
SOC 2 Type II Relevance¶
CloudTaser supports the following SOC 2 Trust Services Criteria:
| Criteria | Category | CloudTaser Contribution |
|---|---|---|
| CC6.1 | Logical and physical access controls | eBPF enforces process-level access controls that prevent even root from reading protected memory. Vault Kubernetes auth ensures only authorized pods access secrets |
| CC6.3 | Authorized access to assets | Only pods with the correct ServiceAccount and namespace binding can authenticate to vault. The operator controls which pods receive injection |
| CC6.6 | Measures against threats | eBPF detects and blocks 20+ attack vectors in real time |
| CC6.7 | Restriction of data transmission | eBPF blocks unauthorized sendto, sendmsg, sendfile, splice, and io_uring operations from protected processes |
| CC7.2 | Monitoring for anomalies | eBPF agent generates security events for all blocked operations, suitable for SIEM ingestion |
| CC7.3 | Evaluation of security events | cloudtaser audit produces structured reports (text and JSON) for ongoing evaluation |
Component-to-Requirement Mapping¶
The following table shows which CloudTaser components contribute to each regulatory framework:
| Component | GDPR Art. 32 | Schrems II | NIS2 | DORA | ISO 27001 | SOC 2 |
|---|---|---|---|---|---|---|
| Operator (webhook injection) | Confidentiality | Supplementary measure | Risk management | ICT tools | A.8.9 | CC6.3 |
| Wrapper (secret delivery) | Encryption, confidentiality | Key control in EU | Cryptography | Protection | A.8.24 | CC6.1 |
| eBPF (runtime enforcement) | Ongoing confidentiality | Technical measure | Incident handling | Detection, response | A.8.12 | CC6.6, CC7.2 |
| S3 Proxy (client-side encryption) | Encryption at rest | Key control in EU | Cryptography | Protection | A.8.24 | CC6.7 |
| CLI (audit, validate, discover) | Testing and evaluation | Documentation | Risk analysis | Risk assessment | A.8.9 | CC7.3 |
Audit Report Integration¶
CloudTaser produces audit reports that can be used as evidence for compliance assessments:
# Generate a compliance audit report
cloudtaser audit --vault-address https://vault.eu.example.com
# JSON output for compliance tooling
cloudtaser audit --vault-address https://vault.eu.example.com -o json
The audit report includes:
- Count and list of protected workloads (CloudTaser-injected)
- Count and list of unprotected workloads (still using K8s Secrets)
- Orphaned Kubernetes Secrets in etcd
- eBPF enforcement coverage per node
- Per-workload protection scores
This data maps directly to the compliance requirements above and can be included in:
- GDPR Records of Processing Activities (Article 30)
- NIS2 risk management documentation (Article 21)
- DORA ICT risk assessment reports (Article 6)
- ISO 27001 Statement of Applicability
- SOC 2 Type II evidence packages