EU Data Act (Regulation (EU) 2023/2854)¶
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.
Framework Overview¶
Full name: Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data (EU Data Act) Entered into force: 11 January 2024 Applicable from: 12 September 2025 Type: EU Regulation (directly applicable in all Member States)
The EU Data Act establishes rules for data sharing, cloud switching, data portability, and safeguards against unlawful international government access to non-personal data. It is a broad regulation covering IoT data access, B2B data sharing, cloud service switching, and international data protection.
Who Must Comply¶
- Cloud service providers (IaaS, PaaS, SaaS) operating in the EU
- Customers of cloud services (data holders and users)
- Manufacturers of connected products (IoT)
- Entities involved in B2B data sharing
Structure¶
The Data Act contains 11 chapters. The most relevant to cloudtaser are:
- Chapter III (Articles 8-12): B2B data sharing obligations
- Chapter VI (Articles 23-31): Cloud switching and data portability
- Chapter VII (Articles 32-34): Safeguards against unlawful international government access
Chapter III -- B2B Data Sharing¶
Articles 8-12 establish rules for making data generated by connected products available to third parties. While primarily focused on IoT data, the principles apply to any data sharing arrangement where cryptographic protection is needed.
| Data Act Requirement | Article | cloudtaser Mapping | Component |
|---|---|---|---|
| Data made available must be protected against unauthorized access | Art. 8(6) | The customer operates EU-hosted OpenBao and controls access policies. Delivery creates no Kubernetes Secret for the value; shared identities, raw login and application copies remain subject to the caveats above | Wrapper |
| Trade secret protection during data sharing | Art. 8(6), Art. 11 | The customer controls the EU store and its keys. Delivery avoids a Kubernetes Secret for the value; that does not establish protection of trade-secret data after the authorised application receives or shares it | Wrapper, S3 Proxy |
| Technical measures to preserve data integrity | Art. 8(6) | S3 proxy provides client-side AES-256-GCM encryption with integrity verification. DB proxy provides transparent encryption for database records | S3 Proxy, DB Proxy |
Chapter VI -- Cloud Switching and Data Portability¶
Articles 23-31 require cloud providers to eliminate barriers to switching between providers and ensure data portability. cloudtaser directly supports these requirements by decoupling secret management from the cloud provider.
| Data Act Requirement | Article | cloudtaser Mapping | Component |
|---|---|---|---|
| Remove barriers to switching | Art. 23 | cloudtaser stores secrets in a portable EU OpenBao (OpenBao), not in the cloud provider's secret management service (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault). Switching providers does not require re-engineering secret management | Wrapper, Operator |
| Functional equivalence during transition | Art. 23(1)(b) | cloudtaser works identically across AWS, GCP, and Azure. The same OpenBao configuration, annotations, and eBPF policies apply on any Kubernetes distribution | Operator |
| Data portability | Art. 24 | Secrets and encryption keys are in a standard OpenBao format, not locked to any provider's proprietary format. Export and import use standard OpenBao CLI tools | Wrapper |
| Gradual reduction of switching charges | Art. 29 | cloudtaser has no switching charges. OpenBao is customer-owned and customer-operated. Moving to a new cloud provider requires only redeploying the cloudtaser operator and wrapper on the new cluster | Operator |
| Interoperability and open standards | Art. 30 | cloudtaser uses standard Kubernetes APIs (admission webhooks, ServiceAccounts, RBAC). OpenBao uses the standard OpenBao API. No proprietary protocols | Operator, Wrapper |
How cloudtaser Enables Cloud Switching¶
-
Before cloudtaser: Secrets are stored in the cloud provider's native secret management service. Switching providers requires migrating all secrets, updating all application configurations, and re-implementing access controls. This creates vendor lock-in.
-
With cloudtaser: Secrets are stored in a portable EU OpenBao. The cloud provider's infrastructure runs the workloads; secret confidentiality remains conditional on the trust boundaries above. Switching providers means:
- Deploy cloudtaser operator on the new cluster
- Point the wrapper at the same EU OpenBao
- Workloads resume with the same secrets, same access policies, same eBPF enforcement
- No secret migration required
Chapter VII -- Safeguards Against Unlawful International Government Access¶
Articles 32-34 are the most directly relevant to cloudtaser. They require cloud providers to implement technical, legal, and organizational measures to prevent non-EU government access to data held in the EU that would conflict with EU or Member State law.
Article 32 -- International Governmental Access and Transfer¶
| Data Act Requirement | cloudtaser Mapping | Component |
|---|---|---|
| Take all adequate technical measures to prevent non-EU government access that conflicts with EU law | Active BPF LSM denies covered procfs/ptrace read paths. Unrestricted node root, arbitrary kernel code and separate store logins remain outside that guarantee | Wrapper, eBPF |
| Take all adequate organizational measures | No CloudTaser technical control establishes organizational compliance. The customer must define access ownership, incident handling, provider contracts and lawful-access processes; runtime evidence can support that review | All |
| Publish description of technical measures on website | cloudtaser-cli target audit generates detailed reports of active protection measures. These reports document the technical safeguards in place |
CLI |
Article 32 -- Specific Technical Measures¶
cloudtaser implements the following technical measures that address Article 32's requirements:
| Threat Vector | cloudtaser Measure | How It Prevents Access |
|---|---|---|
| Cloud provider reads secrets from storage | Delivery creates no Kubernetes Secret for the value | Tested API-object value sweeps do not prove absence from application output, disk or swap; assess those separately |
| Cloud provider reads secrets from memory | memfd_secret (kernel 5.14+) removes pages from kernel direct map |
Direct-map alias removed; arbitrary kernel code, application copies and external hypervisor access are separate boundaries |
Cloud provider uses ptrace to extract secrets |
eBPF blocks ptrace attach/seize on protected processes |
System call denied before execution |
Cloud provider reads /proc/pid/mem |
eBPF blocks /proc/pid/mem and /proc/pid/environ reads by external processes |
File access denied |
| Cloud provider loads kernel module for memory access | memfd_secret removes the secret pages' direct-map alias; module-loading telemetry alone does not deny arbitrary kernel code. Node module/BPF loading policy and integrity need separate verification |
Module-loading telemetry does not prove denial or confidentiality against arbitrary kernel code |
| US government issues CLOUD Act subpoena | The customer controls the store operator and its legal/access processes. CloudTaser documents specific technical boundaries; it does not determine lawful disclosure obligations or prevent every provider access path | No immunity to legal compulsion is established; assess the exact deployment and available access paths |
Article 33 -- Conditions for Lawful International Access¶
Article 33 specifies the conditions under which international government access to non-personal data may be lawful (e.g., via international agreements, mutual legal assistance treaties). cloudtaser does not interfere with lawful access conducted through proper EU legal channels -- the EU entity controlling OpenBao can comply with lawful EU government requests.
Article 34 -- Commission Powers¶
Article 34 empowers the Commission to develop harmonized standards for the technical measures required by Article 32. cloudtaser's architecture aligns with the expected direction of these standards: client-side encryption, EU key control, and runtime memory protection.
Component Coverage Matrix¶
| cloudtaser Component | Data Act Chapters Addressed |
|---|---|
| Operator (webhook injection) | Chapter VI (switching, portability, interoperability) |
| Wrapper (secret delivery) | Chapter III (data protection), Chapter VI (portability), Chapter VII (government access) |
| eBPF (runtime enforcement) | Chapter VII (government access prevention) |
| S3 Proxy (client-side encryption) | Chapter III (data integrity), Chapter VII (government access) |
| DB Proxy (transparent encryption) | Chapter III (data integrity), Chapter VII (government access) |
| CLI (audit, validate, discover) | Chapter VII (transparency, documentation) |
Gaps and Limitations¶
| Data Act Area | Gap | Mitigation |
|---|---|---|
| Chapter II (IoT data access) | cloudtaser does not address IoT data access obligations | Outside scope. cloudtaser protects secrets and encryption keys, not IoT data flows |
| Chapter IV (unfair contract terms) | cloudtaser does not address contractual fairness | Legal/contractual measure, outside product scope |
| Chapter V (B2G data sharing) | cloudtaser does not address government data sharing requirements | Outside scope. cloudtaser protects against unauthorized government access, not authorized data sharing |
| Personal data handling | Chapter VII Articles 32-34 apply specifically to non-personal data. For personal data, GDPR transfer mechanisms (Schrems II supplementary measures) apply | cloudtaser's Schrems II mapping covers personal data. The technical measures are the same |
| Full provider compliance | The Data Act places obligations on cloud providers, not their customers | cloudtaser helps customers implement technical measures that satisfy the provider's Article 32 obligations. Customers should verify their provider also complies with Chapters VI and VII |
Data Act and Schrems II overlap
Article 32 of the Data Act (non-personal data) and Schrems II supplementary measures (personal data) both require technical measures against non-EU government access. cloudtaser's technical controls satisfy both requirements simultaneously. See the Regulatory Mapping page for the Schrems II mapping.
Audit Evidence¶
cloudtaser produces evidence relevant to Data Act compliance:
# Generate compliance audit report
cloudtaser-cli target audit --secretstore-address https://vault.eu.example.com
# JSON output for evidence packages
cloudtaser-cli target audit --secretstore-address https://vault.eu.example.com -o json
The audit report provides:
- Cloud-agnostic deployment verification (Chapter VI portability)
- EU OpenBao connectivity verification (Chapter VII data sovereignty)
- Protection scores per workload (Chapter VII technical measures)
- eBPF enforcement coverage (Chapter VII government access prevention)
- Orphaned Kubernetes Secrets inventory (data in US-controlled storage)