Compliance and Regulatory Mapping¶
Authorised application boundary
Authorised application code is trusted. An authorised app can send out a secret it has copied or encoded. Current content checks do not provide a general guarantee against this disclosure or a malicious authorised app. Memory-read tests and a Ready agent do not prove copied/encoded-secret exfiltration prevention. Enforced NetworkPolicy can restrict destinations, but allowed traffic remains a channel. See Security Model.
Workload identity and direct store-login boundary
In direct mode, OpenBao authenticates the ServiceAccount and namespace, not the injected wrapper. Anyone who can run a pod as the application's ServiceAccount can request a matching audience-bound JWT, log in to any store role bound to that identity, and read the records its policies allow. Node root can steal the projected JWT and do the same. CloudTaser does not bind direct store release to the injected wrapper. This limit remains unresolved. Blocking exec or protecting process memory does not block a separate store login. Port/bootstrap attestation claims do not apply to direct-mode logins.
Use one workload per identity: a dedicated ServiceAccount and exact-record store policy for each app. Restrict who can create or change workloads using that ServiceAccount, including controller templates, through Kubernetes RBAC and admission policy. Namespace access alone is not isolation between apps sharing an SA. Audience checks, shorter JWT lifetimes and source CIDRs limit some replay; they do not establish wrapper identity or stop node root. Confidentiality claims on this page do not cover this credential-acquisition path.
One workload per identity applies on both direct and Port paths. Denial of a second same-identity workload on Port has not been established; a different-ServiceAccount reader test does not prove that denial.
Mapping, not certification
This document maps cloudtaser's technical controls to the named framework's requirements. It is evidence you can present to your auditor, not a cloudtaser certification. Certification is an outcome of your auditor's own review of your deployment (which may use cloudtaser's controls as supporting input).
Third-party audit roadmap: tracked in third-party audit roadmap. Target: Q2 2026. Until the audit completes, cloudtaser ships with deliberately-documented gaps rather than certification claims.
What this document IS / IS NOT¶
This is:
- A mapping of cloudtaser technical controls to framework requirements
- Evidence you can include in your auditor's evidence package
- A starting point for your DPIA / compliance narrative
This is NOT:
- A cloudtaser framework certification
- A substitute for your own audit/attestation/assessment
- Legal advice
Use this to accelerate your audit preparation, not to replace audit evidence.
How cloudtaser helps EU enterprises meet regulatory requirements for data protection, operational resilience, and information security when running workloads on US cloud providers.
For engineers
Each compliance control maps to specific cloudtaser components. Engineers can verify coverage using cloudtaser-cli target audit and protection scores.
For leadership
cloudtaser maps to 12+ regulatory frameworks. The audit command generates evidence packages for compliance assessments.
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 | The customer operates the EU store; delivery uses TLS and creates no Kubernetes Secret for the value. Tested API-object/log sweeps found no tested-value matches. This does not establish absence from application output, disk or swap, or encrypt stored application data |
| Ongoing confidentiality | Active BPF LSM denies covered procfs/ptrace read paths. Unrestricted node root, arbitrary kernel code and separate store logins remain outside that guarantee |
| Pseudonymisation | Masking/pseudonymisation keys can be held in the customer-operated EU OpenBao and delivered to workload memory. Application copies and use of those keys remain trusted; this does not prove the provider cannot re-identify data |
| Regular testing and evaluation | cloudtaser-cli target 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 | The customer operates the EU store and controls its at-rest keys. Delivery uses TLS and creates no Kubernetes Secret for the value. Workload memory/copies are a separate boundary; Port/beacon delivery does not encrypt stored application data |
| Measure 2: Pseudonymised data processing | Pseudonymisation keys can be stored in the customer-operated EU OpenBao and delivered without creating a Kubernetes Secret for the value. Key use, application output and re-identification risk need separate assessment |
| Measure 4: Encryption by the data exporter with sole key control | The customer operates the EU OpenBao and controls its administrative access, policies and store-key custody. Workload credentials or encryption-key copies still require the identity, application and runtime safeguards above; this is not proof of exclusive access under node compromise |
| Measure 9: Processing only in the EEA | The customer operates the store on its selected EU substrate. Workload processing can still occur outside the EEA; an EU store alone does not meet an EEA-only processing requirement. Assess all runtime, relay and output locations |
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. The following controls reduce covered access paths, subject to the identity and node-integrity limits above:
memfd_secret(kernel 5.14+) removes secret pages from the kernel direct map. This does not isolate secrets from arbitrary kernel code, application copies or the hypervisor- eBPF enforcement blocks
ptrace,/proc/pid/memreads,process_vm_readv, and other memory access syscalls targeting protected processes - Delivery avoids Kubernetes Secret values -- no Kubernetes Secret is created for the delivered value. API-object checks do not establish absence from application output, disk, swap or core dumps
Technical vs contractual measures
Schrems II requires supplementary measures that go beyond contractual guarantees. cloudtaser supplies technical controls for specific paths. These do not prove immunity to provider access or legal compulsion; assess raw store login, node integrity, application behavior and confidential-compute evidence separately.
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-cli target audit provides a security posture report. Protection scores quantify the level of runtime protection per workload |
| (b) Incident handling | Configured runtime checks cover specific paths and patterns. An authorised app can disclose copied or encoded secrets; no general prevention guarantee is established. Enforced egress policy narrows destinations but allowed channels remain |
| (d) Supply chain security | Controlled key storage and runtime enforcement reduce specific exposure paths; supply-chain compromise, raw login and authorized application output remain risks |
| (e) Security in network and information systems acquisition | cloudtaser-cli target validate and cloudtaser-cli target 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 | ServiceAccount/namespace role bindings and exact-record policies limit store access; direct login is not bound to the wrapper or Deployment. See the identity caveat above |
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-cli target 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-cli target 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 | Configured runtime checks cover specific paths and patterns. An authorised app can disclose copied or encoded secrets; no general prevention guarantee is established. Enforced egress policy narrows destinations but allowed channels remain |
| 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) as an additional response action; it does not count as enforcement or toward readiness under the default chart. 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-cli target audit supplies workload/component observations for third-party review. The customer remains responsible for provider assessment, identity controls, kernel integrity and compute qualification; the report does not quantify residual risk |
| Art. 30 -- Key contractual provisions | CloudTaser does not establish contractual provisions or audit rights. The customer must agree and review them with its providers; technical controls and reports are supporting inputs, not a substitute |
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 | ServiceAccount/namespace role bindings and exact-record policies limit store access; direct login is not bound to the wrapper or Deployment. See the identity caveat above |
| A.8.7 | Protection against malware | eBPF blocks code injection via ptrace and process memory write |
| A.8.9 | Configuration management | cloudtaser-cli target validate verifies correct configuration. cloudtaser-cli target audit detects drift |
| A.8.10 | Information deletion | Delivery creates no Kubernetes Secret for the value. Application copies, logs, disk/swap data and store backups require separately verified retention/deletion controls |
| A.8.11 | Data masking | cloudtaser can be used to protect data masking keys in process memory |
| A.8.12 | Data leakage prevention | Configured runtime checks cover specific paths and patterns. An authorised app can disclose copied or encoded secrets; no general prevention guarantee is established. Enforced egress policy narrows destinations but allowed channels remain |
| A.8.20 | Networks security | Network policies restrict communication to the OpenBao endpoint. cloudtaser-cli target netpol generates policies automatically |
| A.8.24 | Use of cryptography | All OpenBao 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-cli target 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 | ServiceAccount/namespace role bindings and exact-record policies limit store access; direct login is not bound to the wrapper or Deployment. See the identity caveat above |
| CC6.3 | Authorized access to assets | OpenBao authenticates the ServiceAccount/namespace identity. Any holder of its matching JWT can perform raw direct login; workload creation and identity reuse must be controlled |
| CC6.6 | Measures against threats | eBPF source catalogues 37 kprobe syscall programs; qualify runtime detection and denial on the selected path |
| CC6.7 | Restriction of data transmission | Configured runtime checks cover specific paths and patterns. An authorised app can disclose copied or encoded secrets; no general prevention guarantee is established. Enforced egress policy narrows destinations but allowed channels remain |
| 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-cli target 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-cli target audit --secretstore-address https://vault.eu.example.com
# JSON output for compliance tooling
cloudtaser-cli target audit --secretstore-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