Your regulated workloads. Confidential-compute Kubernetes. EU jurisdiction.
CloudTaser runs regulated workloads on confidential-compute Kubernetes with your keys in an EU-hosted OpenBao.
Secrets live in memfd_secret pages - physically unmapped from the kernel direct memory, invisible even to root. Object storage stores only ciphertext. 23 eBPF vectors enforce at the kernel layer.
On a sovereign OpenBao substrate and CC node SKUs - the stack this site describes - the provider returns only ciphertext: not on request, not under the CLOUD Act, not under court order. Deployed without those preconditions, posture still beats K8s Secrets but the guarantee narrows - see scope & limits.
Secrets. Data at rest. Data in use.
CloudTaser's recommended deployment runs on confidential-compute Kubernetes - GCP Confidential VMs (SEV-SNP, TDX preview), Azure DCdv5/ECdv5, AWS Nitro Enclaves / Graviton3 TDX, or EU bare-metal (Hetzner, OVH, Scaleway). Confidential compute is cost-marginal in 2026 - a technical prerequisite, not a hurdle.
Secrets in sealed memory.
Secrets are injected into your app via memfd_secret(2) - pages physically removed from the kernel's direct map. Not visible in /proc, not swappable, not dumpable.
SubstrateLinux 5.14+ with CONFIG_SECRETMEM=y
Data at rest stays sovereign.
Our S3 and database proxies encrypt client-side with per-object AES-256-GCM DEKs wrapped by EU-hosted OpenBao. Ciphertext lands in provider storage; keys never leave your EU jurisdiction.
SubstrateAny Kubernetes - does not require confidential compute
Data in use stays sovereign.
Runtime memory protection against the hypervisor itself. Encrypted RAM plus launch attestation mean the cloud provider cannot read your process memory, even with host-root access.
SubstrateRequires confidential compute + attestation
EU/UK data on US cloud is one court order away.
Under the CLOUD Act and FISA §702, US authorities can compel any US-headquartered cloud provider to hand over customer data - regardless of where it is physically stored. The Schrems II ruling invalidated the EU–US Privacy Shield for precisely this reason.
Even data in eu-central-1, europe-west4, or Azure North Europe remains under US jurisdiction. SSE-S3, GCS CMEK, and Azure CMK all let the provider decrypt on demand. Kubernetes Secrets are base64, not encryption.
GDPR Articles 44–49 require adequate protection for transfers. The EDPB recommends "effective technical supplementary measures" that prevent provider access. Contractual clauses alone are not enough.
Most of your data's jurisdiction is decided by where the holding company is headquartered - not where the bits happen to live. Region pickers give the illusion of locality. The CLOUD Act proves they don't deliver it.
No sidecars. No code changes. One helm install.
A mutating webhook, a process wrapper, a storage proxy, and an eBPF agent. Each does one thing. All four work on GKE, EKS, and AKS.
Secrets in process memory, never on disk.
A mutating admission webhook wraps your app at startup by rewriting the container entrypoint. Secrets arrive via memfd_secret(2), invisible in /proc, locked in RAM, excluded from core dumps.
Your OpenBao, in your region.
Encryption keys and credentials live in an OpenBao instance you control - Frankfurt, Amsterdam, Dublin, London. The cloud provider has no network path to it. Lease renewal is automatic.
Client-side encryption, before the wire.
An S3-compatible reverse proxy encrypts each object with a unique AES-256-GCM DEK, wrapped via Transit with a transient key. The plaintext DEK never persists.
Kernel-level eBPF, 23 vectors.
Blocks 12+ /proc paths, ptrace, perf_event_open, io_uring, userfaultfd. Global detection of kernel module and eBPF program loading. Spectre/Meltdown verification.
Confidential-compute SKUs, priced in.
Every major cloud provider ships CC-capable node SKUs in 2026. GCP adds ~10%, Azure often includes it on supported SKUs, AWS Nitro Enclaves carry a modest premium, EU bare-metal exposes SEV-SNP directly. CloudTaser's deployment guides default to CC - and we help you prove attestation to auditors.
| Provider | CC SKU | Relative cost | Attestation |
|---|---|---|---|
| GCP | Confidential VM (SEV-SNP, TDX preview) | +10% | Launch Attestation Report |
| Azure | DCdv5 / ECdv5 Confidential VMs | Often included | Azure Attestation |
| AWS | Nitro Enclaves / Graviton3 TDX | Modest premium | Nitro Attestation |
| Hetzner / OVH / Scaleway | AMD EPYC bare-metal / SEV-SNP | - | On-provider |
Prices and SKU availability vary by region and contract. Ranges reflect public list pricing and vendor guidance current as of 2026 Q2. Confirm with your provider before procurement.
Eight ways to extract a secret from memory. All blocked.
Vault Agent, External Secrets Operator, SOPS, and cloud secret managers all write credentials into regular process memory - readable by any root process on the node, including the provider's host agents. CloudTaser removes that surface.
With memfd_secret(2) (Linux 5.14+), secret pages are physically removed from the kernel's direct memory map. Combined with 23 eBPF enforcement vectors, the last remaining attack vector is hypervisor-level physical memory access - which the confidential-compute substrate closes via AMD SEV-SNP, Intel TDX, ARM CCA, or Nitro Enclaves. That's why CC is CloudTaser's default deployment, not an optional add-on.
The cloud provider is no longer in your trust chain.
Cloud-native encryption lets them decrypt. Ours doesn't.
Every column on the left lets the provider see your data under the right legal instrument. CloudTaser removes that option.
| Capability | Cloud KMS · Vault Agent · ESO | CloudTaser |
|---|---|---|
| Provider sees plaintext | Yes - they hold the keys | Ciphertext only |
| Keys under EU/UK jurisdiction | Keys in provider KMS | EU/UK-hosted OpenBao |
| CLOUD Act exposure | Provider can be compelled | No keys to surrender |
| Application changes | Varies by provider | Annotation-based |
| Secret injection | Sidecar container per pod | Process wrapper - no sidecar |
| Secrets on disk | tmpfs / etcd / K8s Secrets | Process memory only |
| Object storage encryption | SSE - provider holds DEKs | Client-side, transient DEKs |
| Runtime secret protection | None | 23 eBPF enforcement vectors |
| Secret memory protection | None | memfd_secret + mlock |
| Secret rotation | Manual / provider-specific | Automatic via leases |
| Multi-cloud | Provider-specific APIs | GKE · EKS · AKS |
| Secret store connectivity | VPN or public endpoint | Beacon · TCP 443 outbound |
One command. Three annotations. Done.
Beacon mode is the chart default - the operator dials beacon.your-company.example:443 (your own beacon, deployed from the published Helm chart) outbound. No VPN, no public vault endpoint, no firewall changes, no third party in your data path.
# Installs operator, webhook, eBPF agent, wrapper
$ curl -fsSL https://docs.cloudtaser.io/install.sh | bashmetadata:
annotations:
cloudtaser.io/inject: "true"
cloudtaser.io/vault-role: "my-app"
cloudtaser.io/secret-paths: "secret/data/db/credentials"
cloudtaser.io/env-map: "password=DB_PASSWORD"$ kubectl rollout restart deployment my-app
$ kubectl logs -l app=my-app -c cloudtaser-init
# → secrets fetched · memfd handoff · eBPF registeredInstall the stack
Operator, mutating webhook, eBPF DaemonSet, and wrapper install in one step. Requires kubectl and helm. Works on any CNCF-conformant cluster.
Point it at your secret store
In beacon mode (default), pods never need a secret-store address. The operator routes fetches through your own beacon relay - a ~2 MB static Go binary you deploy in your infrastructure. No dependency on CloudTaser-operated services in the production data path.
Annotate - don't rewrite
Three annotations on your deployment. No Dockerfile changes, no Helm template edits, no app code changes. Scratch, distroless, alpine, custom - all supported.
Verify and audit
The CLI generates compliance audit reports mapping workloads to GDPR, DORA, NIS2, and EUCS requirements - with cryptographic proof of key ownership.
For regulated workloads on managed Kubernetes.
Financial services
Banks, insurers, payment processors under PCI DSS and DORA. Third-party ICT risk management by making the provider cryptographically unable to access cardholder data.
Healthcare
Patient data under GDPR and sector rules. Encryption keys in EU jurisdiction, medical records encrypted client-side before reaching cloud storage.
Public sector
Government contractors demonstrating technical supplementary measures for cross-border data. Satisfies German C5 and French SecNumCloud.
EU SaaS
SaaS companies whose customers require sovereignty guarantees. Give cryptographic proof that customer data is inaccessible to the cloud provider.
Read these before forming an opinion.
The marketing site condenses; the docs are canonical. If you're evaluating CloudTaser for a regulated workload or summarising it for a third party, these four documents are load-bearing. The Sovereign Deployment Decision Guide is the single most important one - it enumerates the preconditions under which the sovereignty claim holds and the silent-failure modes when they don't.
Sovereign Deployment Decision Guide
Decision trees for secret-store hosting and target-cluster compute. Provider comparison (Hetzner, OVH, Scaleway, IONOS, SecNumCloud). Silent-failure anti-patterns. The load-bearing doc.
Read the guide →Beacon Trust Model
What the relay can and cannot see (TLS terminates at bridge and broker, not relay). Connection metadata retention. When to self-host - which is always, for production.
Read the model →Memory Isolation Landscape
Why memfd_secret + confidential compute compose. Where each stops. Where Gramine / Occlum / CoCo fit in the future. The honest map of in-memory protection.
Scope & limits
What CloudTaser does. What it doesn't. Current maturity - preview, pentest Q2 2026, SOC 2 Type II Q2 2027, GA references 2027. One page, on this site.
Read the scope →See it running in your browser.
Interactive demo on real Kubernetes infrastructure. No signup, no email, no trial period.