CloudTaser — Competitive Positioning¶
For: CISO / Head of Security, EU-regulated financial services Version: March 2026
What CloudTaser Is¶
CloudTaser is a Kubernetes-native data sovereignty layer that cryptographically severs the connection between your workloads and your US cloud provider's key management infrastructure. It injects a sidecar via mutating admission webhook, delivers secrets from an EU-hosted vault directly into process memory using memfd_secret, and enforces at the kernel level via eBPF — so neither the cloud provider nor a US court order can reach your plaintext.
The Problem That None of Your Current Tools Solve¶
Data residency is not data sovereignty.
When your workload runs on AWS eu-west-1, your data is physically in Ireland. But AWS is a US company. The CLOUD Act (2018) and FISA Section 702 allow US government agencies to compel any US-controlled provider to produce data — regardless of where the servers sit. Jurisdiction follows corporate ownership, not geography. No "EU region" election, no Standard Contractual Clause, and no Data Privacy Framework designation changes this.
DORA, in force since January 2025, makes this a regulatory exposure, not just a theoretical risk. Article 28 requires financial entities to identify, assess, and demonstrably manage ICT concentration risk. In November 2025, the ESAs designated AWS, Azure, and Google Cloud as critical ICT third-party providers subject to direct EU supervision — which means your regulators are now actively examining whether those dependencies can be compelled to expose data. The question your next audit will ask is not "where is the data?" It is "who holds the keys, and under what legal jurisdiction?"
Comparison Matrix¶
| Capability | CloudTaser | HashiCorp Vault + CSI | External Secrets Operator | AWS/GCP/Azure Secret Manager | Sealed Secrets | Infisical | Conjur (CyberArk) |
|---|---|---|---|---|---|---|---|
| Secrets never enter etcd | Yes | No — tmpfs on node | No — syncs to K8s Secrets | No — syncs to K8s Secrets | No — decrypts to K8s Secrets | No | No |
| Secrets delivered to process memory only (memfd_secret) | Yes | No | No | No | No | No | No |
| Keys held exclusively in EU jurisdiction | Yes | Depends — HCP Vault is US SaaS | No | No — provider controls keys | No | No — US SaaS control plane | Depends |
| Zero code changes to workload | Yes | Partial — requires CSI volume mounts | Partial — requires K8s Secret references | No — SDK or sidecar required | No | No | No |
| eBPF kernel-level enforcement | Yes | No | No | No | No | No | No |
| Blocks /proc/PID/mem secret exfiltration | Yes | No | No | No | No | No | No |
| Quantifiable protection score for auditors | Yes | No | No | No | No | No | No |
| CLOUD Act / FISA 702 technical mitigation | Yes | No | No | No | No | No | Partial |
| Open-source vault backend | Yes — OpenBao | Yes — but BSL license | No | No | Yes | No | No |
| Works on GKE, EKS, AKS | Yes | Yes | Yes | Yes | Yes | Yes | No — heavy integration |
Why CloudTaser¶
1. The only tool where secrets never leave vault memory.
Every alternative in the matrix above — Vault CSI, ESO, Sealed Secrets, cloud-native secret managers — ultimately writes secrets to etcd or a tmpfs volume the host kernel can read. CloudTaser uses Linux memfd_secret syscall to create anonymous memory regions inaccessible to other processes and to /proc inspection. The secret lifecycle is: vault → TLS → sidecar memory → target process. There is no disk path, no etcd record, no K8s Secret object.
2. Runtime enforcement is cryptographic, not policy-based.
The eBPF daemonset operates at the kernel syscall boundary. It does not rely on admission policies, RBAC rules, or audit logs that can be bypassed by a sufficiently privileged operator. It actively blocks ptrace, /proc/PID/mem reads, and syscall patterns associated with secret exfiltration — and generates tamper-evident audit events. This is the difference between "we have a policy" and "we have evidence the policy was enforced."
3. EU jurisdiction for the control plane is not optional. CloudTaser deploys your OpenBao vault into EU-hosted infrastructure you control. The key material never enters a US provider's key management system. This is the technical supplementary measure that EDPB guidance requires when SCCs alone are insufficient — and the one that makes a CLOUD Act production order technically unexecutable against your data content.
4. Quantified posture, not a checkbox. CloudTaser's protection score gives your CISO, DPO, and external auditor a single metric that reflects the actual sovereignty state of each workload — not a static policy document that may drift from reality. Score changes propagate to your audit trail in real time.
Anticipated Objections¶
"We already use HashiCorp Vault." Where does Vault run? If it runs on EKS or GKE — even with customer-managed keys — the encryption keys for Vault's storage backend are managed by AWS KMS or GCP KMS. That is a US-jurisdiction key custodian. If it runs as HCP Vault, the control plane is US SaaS. CloudTaser is not a replacement for Vault's API surface — it is an enforcement layer that ensures the secrets Vault issues never touch the cloud provider's infrastructure again after they leave the vault.
"We've selected an EU region and our DPA covers this." The CLOUD Act does not require a server to be in the US. It requires the company holding the data to be US-incorporated or to do business in the US. Your DPA with AWS is a contractual instrument; a US court order supersedes it. The EDPB's guidance on supplementary measures explicitly states that contractual and organisational measures alone are insufficient when the legal framework of the third country permits access without adequate protection. A technical measure — customer-controlled keys in EU jurisdiction — is required.
"This is operationally complex to deploy." The mutating admission webhook is installed once via Helm. There are no SDK changes, no code changes, and no per-application configuration beyond an annotation on the Pod spec. Existing workloads using environment variable references to AWS Secrets Manager or GCP Secret Manager are intercepted transparently. The median time from Helm install to first sovereign workload is under 30 minutes in a standard EKS or GKE environment.
"We're evaluating confidential computing (Azure ACC, GCP CVM)." Confidential computing protects memory from the hypervisor at runtime — it does not address key jurisdiction. The attestation and key release mechanism in Azure ACC and GCP CVM involves the cloud provider's attestation service. The provider can still be compelled to modify the attestation policy or produce the sealing keys. These are complementary controls, not substitutes for EU-jurisdiction key management.
CloudTaser is produced by skipOPS Ltd. Architecture documentation, threat model, and OpenBao deployment reference available at docs.cloudtaser.io.