ANSSI SecNumCloud -- French Cloud Security Qualification¶
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: Referentiel SecNumCloud v3.2 Issued by: ANSSI (Agence nationale de la securite des systemes d'information -- National Agency for Information Systems Security, France) Current version: v3.2 (2022) Type: Cloud security qualification (provider certification)
SecNumCloud is ANSSI's qualification framework for cloud service providers. It imposes over 360 requirements across 14 security themes, with a focus on ensuring that cloud data is protected from non-EU extraterritorial laws (particularly US CLOUD Act and FISA 702). SecNumCloud v3.2 introduced strict sovereignty requirements including EU ownership caps and data localization mandates.
Who Must Comply¶
- Cloud providers serving the French government, defense, and critical infrastructure
- Cloud providers processing sensitive data for French public and private organizations
- Increasingly referenced in French and EU procurement as the gold standard for sovereign cloud
Key Principles¶
- Immunity from non-EU laws: The provider must not be subject to extraterritorial non-EU legislation that could compel data disclosure
- EU data residency: All customer data and technical data must be stored and processed within the EU
- EU ownership and control: Non-EU shareholders capped at 25% individually, 39% collectively
- End-to-end encryption: Systematic encryption with keys under EU control
Relevant SecNumCloud Requirements and cloudtaser Mapping¶
Data Localization¶
| SecNumCloud Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| Data residency in EU | All customer data must be stored on servers located in the EU | OpenBao (the key store) is hosted exclusively in the EU. Secrets never persist outside process memory -- they do not reach etcd, disk, or any US-controlled storage layer | Wrapper |
| Technical data in EU | System logs, metadata, and technical data must remain in the EU | eBPF security events and audit logs are generated locally on the Kubernetes cluster. cloudtaser does not transmit telemetry to non-EU destinations | eBPF, CLI |
| Support operations in EU | All system administration and support must be conducted from within the EU by EU-based personnel | cloudtaser is self-hosted on the customer's Kubernetes cluster. No remote access or external support channel exists by default. The SaaS control plane is EU-hosted | Operator |
Encryption and Key Management¶
| SecNumCloud Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| Encryption of data in transit | All data in transit must be encrypted using strong cryptographic protocols | All OpenBao communication uses TLS 1.2+ (mTLS when configured). Secrets are never transmitted in plaintext | Wrapper |
| Encryption of data at rest | Data at rest must be encrypted with keys under the provider's or customer's control | S3 proxy provides client-side AES-256-GCM encryption. Encryption keys remain in the EU-hosted OpenBao and never reach the cloud provider | S3 Proxy |
| Data in use protection | Data being processed must be protected from unauthorized access | 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 |
| EU key control | Encryption keys must remain under the control of an EU entity | The EU-hosted OpenBao (OpenBao) is operated by the EU data controller. The cloud provider has no access to OpenBao keys. This is a technical guarantee, not a contractual one | Wrapper, S3 Proxy |
| Key lifecycle management | Keys must follow a documented lifecycle: generation, storage, rotation, destruction | cloudtaser-cli target rotate supports key rotation. OpenBao manages the key lifecycle within EU jurisdiction. Secret pages in memory are destroyed when processes exit |
Wrapper |
Access Control¶
| SecNumCloud Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| Strict identity management | Only authorized personnel and systems may access data | 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 | Operator, Wrapper |
| Multi-factor authentication | Access to sensitive systems must use MFA | OpenBao supports MFA for human operators. Pod authentication uses Kubernetes ServiceAccount tokens (machine identity), which are audience-bound and short-lived | Wrapper |
| Privileged access control | Privileged access must be strictly controlled and monitored | Active BPF LSM denies covered procfs/ptrace read paths. Unrestricted node root, arbitrary kernel code and separate store logins remain outside that guarantee | eBPF |
| Access logging and audit trail | All access to data must be logged with tamper-evident audit trails | eBPF generates security events for all access attempts (blocked and allowed). OpenBao audit log records all secret fetch operations. cloudtaser-cli target audit produces compliance reports |
eBPF, CLI |
| Separation of duties | Administrative roles must be separated | The operator controls injection policy. OpenBao controls access policy. eBPF enforces runtime policy. No single component has full access | Operator, Wrapper, eBPF |
Immunity from Non-EU Laws¶
| SecNumCloud Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| Protection from extraterritorial laws | The provider must demonstrate that non-EU laws (e.g., US CLOUD Act, FISA 702) cannot compel data disclosure | CloudTaser does not confer legal immunity or provider qualification. The customer must assess the chosen store, compute and relay operators and their access/jurisdiction, alongside the documented technical limits | All |
| Technical measures against compelled disclosure | Technical controls must prevent data access even under legal pressure | Delivery creates no Kubernetes Secret for the value and active enforcement covers specific read paths. Raw login, application disclosure, arbitrary guest-kernel code and unqualified compute remain limits; no blanket compelled-disclosure prevention is established | Wrapper, eBPF |
| Transparency of government access requests | The provider must disclose information about government access requests | No CloudTaser feature establishes provider transparency about government requests. The customer must review provider reporting, notification obligations and disclosure processes | -- |
Incident Detection and Response¶
| SecNumCloud Requirement | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| Security event detection | The provider must detect and respond to security events | Published source catalogues 37 kprobe syscall programs. Event identifiers include: SECRET_LEAK, PROCMEM_READ, ENVIRON_READ, PTRACE_DENIED, MODULE_LOAD, BPF_LOAD |
eBPF |
| Incident response capability | The provider must have documented incident response procedures | On detection of a policy violation, the eBPF agent can block the operation (synchronous deny) and, as an additional response, terminate the offending process (reactive kill). Reactive kill is a response action only: it does not count as enforcement or toward readiness under the default chart. Events are generated for SIEM integration | eBPF |
Component Coverage Matrix¶
| cloudtaser Component | SecNumCloud Themes Addressed |
|---|---|
| Operator (webhook injection) | Access control, identity management, separation of duties |
| Wrapper (secret delivery) | Encryption in transit, data in use, EU key control, data localization |
| eBPF (runtime enforcement) | Privileged access control, incident detection, immunity from non-EU laws, access logging |
| S3 Proxy (client-side encryption) | Encryption at rest, EU key control |
| DB Proxy (transparent encryption) | Encryption at rest, EU key control |
| CLI (audit, validate, discover) | Audit trail, compliance reporting, vulnerability identification |
Gaps and Limitations¶
cloudtaser is a customer-deployed data protection product, not a SecNumCloud-qualified cloud provider. The following areas are outside cloudtaser's scope:
| SecNumCloud Area | Gap | Mitigation |
|---|---|---|
| Provider ownership structure | SecNumCloud requires EU ownership caps (25% individual, 39% collective non-EU). cloudtaser cannot change a provider's ownership | CloudTaser does not remove provider-ownership or legal requirements. Use a qualified infrastructure provider and assess CloudTaser controls within the identity and runtime limits above |
| Physical infrastructure location | SecNumCloud requires EU-located infrastructure. cloudtaser does not control where Kubernetes nodes run | The customer must deploy Kubernetes in EU regions. cloudtaser's OpenBao must be EU-hosted. cloudtaser protects secrets even if the compute layer is in a non-EU jurisdiction |
| Personnel security | SecNumCloud requires EU-based personnel with security clearance for certain roles | Organizational measure, outside product scope. cloudtaser eliminates the need for cloud provider personnel to access secrets |
| Full provider certification | SecNumCloud qualifies cloud providers, not individual products | cloudtaser helps customers achieve SecNumCloud-equivalent protection on non-qualified providers through technical controls rather than provider certification |
| Contractual and legal framework | SecNumCloud includes legal and contractual requirements | cloudtaser provides technical measures. Contractual and legal measures are the customer's responsibility |
SecNumCloud is primarily a provider certification
SecNumCloud qualifies cloud providers, not their customers. cloudtaser helps customers of non-SecNumCloud-qualified providers (AWS, GCP, Azure) achieve equivalent technical protection guarantees. For organizations that require SecNumCloud-qualified infrastructure, cloudtaser provides an additional defense-in-depth layer on top of the qualified provider.
Audit Evidence¶
cloudtaser produces evidence relevant to SecNumCloud assessments:
# 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:
- EU OpenBao connectivity verification (data localization)
- TLS/mTLS configuration details (encryption in transit)
- Protection scores per workload (data in use protection)
- eBPF enforcement coverage per node (privileged access control)
- Orphaned Kubernetes Secrets inventory (data residency risk)