Ultimate Protection

What it takes to make it cryptographically impossible for a US cloud provider or US government to access your secrets and data — even under CLOUD Act warrant, FISA 702 directive, or full root access on the node.

This page is for organizations where "the cloud provider pinky-promises not to look" is not an acceptable security posture: banks, government identity services (DigiD), healthcare platforms, and any EU entity processing data subject to GDPR, DORA, NIS2, or national equivalents.

---

What "Ultimate" Means

CloudTaser at maximum configuration closes every known access path between a US cloud provider and your secrets:

Access Path	How It Is Closed	Guarantee Type
etcd / K8s Secrets API	Secrets never enter Kubernetes storage	Architectural (no data to find)
Disk / swap / core dumps	mlock + MADV_DONTDUMP + PR_SET_DUMPABLE	Kernel enforcement
/proc/PID/mem, /proc/PID/environ	eBPF blocks all reads, environ scrubbed	Runtime enforcement
ptrace / process_vm_readv	eBPF blocks at syscall level	Runtime enforcement
Kernel module injection	eBPF detects init_module / finit_module + reactive kill	Detection + response
Kernel direct memory map	memfd_secret removes pages from direct map	Hardware-backed (Linux 5.14+)
Hypervisor memory inspection	Confidential computing (AMD SEV-SNP / Intel TDX)	Hardware-backed (CPU encryption)
Object storage (S3/GCS/Blob)	S3 proxy encrypts with EU-held keys before upload	Client-side encryption
Network exfiltration	eBPF monitors sendto/sendmsg + NetworkPolicy	Runtime enforcement
Vault key access	Vault runs in EU jurisdiction under EU legal entity	Jurisdictional (EU law applies)

The result

With all layers active, the cloud provider stores only:

• Encrypted VM memory it cannot decrypt (confidential computing)
• Encrypted objects it cannot decrypt (S3 proxy + EU vault keys)
• Ciphertext in transit it cannot decrypt (mTLS to EU vault)

There is nothing to hand over in response to a CLOUD Act warrant because the provider never holds plaintext data or decryption keys.

---

Seven Required Layers

Layer 1: EU-Hosted OpenBao/Vault (HA)

All encryption keys and secrets must be stored in a vault running in an EU data center, operated by an EU legal entity, under EU jurisdiction.

Requirement	Specification
Software	OpenBao (open source, MPL 2.0) or HashiCorp Vault
Deployment	3-node Raft HA cluster
Region	EU only (e.g., europe-west4, eu-central-1, westeurope)
Operator	EU legal entity — not a US subsidiary
Auto-unseal	Cloud KMS with EU-resident keys or on-premises HSM
Network	Private connectivity only (VPC peering / Private Service Connect)

HashiCorp is a US company

While Vault can be self-hosted in the EU, HashiCorp Cloud Platform (HCP Vault) is operated by a US company and may be subject to CLOUD Act. Self-hosted OpenBao operated by an EU entity is the safest choice for ultimate protection.

Layer 2: Confidential Computing Nodes

The Kubernetes worker nodes must run on confidential computing hardware that encrypts VM memory at the CPU level. This closes the hypervisor gap — the only access path that software alone cannot block.

GKEAKSEKS

Confidential GKE Nodes with AMD SEV-SNP:

gcloud container node-pools create secure-pool \
  --cluster=my-cluster \
  --machine-type=n2d-standard-8 \
  --enable-confidential-nodes \
  --region=europe-west4

Supported machine types: n2d-* (AMD EPYC Milan/Genoa with SEV-SNP)

Azure Confidential VMs with AMD SEV-SNP:

az aks nodepool add \
  --resource-group my-rg \
  --cluster-name my-cluster \
  --name securepool \
  --node-vm-size Standard_DC8as_v5 \
  --node-count 3

Supported sizes: DCasv5 / DCadsv5 series (AMD SEV-SNP), DCesv5 / DCedsv5 (Intel TDX)

AWS supports Nitro Enclaves for isolated compute but does not offer full-VM confidential computing with SEV-SNP for general EKS workloads at this time. For ultimate protection on AWS, consider:

• Nitro Enclaves for isolated secret processing
• Bare metal instances (m5.metal, m6i.metal) for self-managed confidential VMs
• AWS Graviton with Realms (ARM CCA, future)

Layer 3: Linux 5.14+ Kernel with memfd_secret

The kernel must support memfd_secret(2) for hardware-backed memory hiding.

Platform	Default Kernel	memfd_secret
GKE (COS)	5.15+	Supported
GKE (Ubuntu)	5.15+	Supported
EKS (AL2023)	6.1+	Supported
AKS (Ubuntu 22.04)	5.15+	Supported
AKS (Azure Linux)	6.1+	Supported

# Force fail-fast if memfd_secret is unavailable
env:
  - name: CLOUDTASER_REQUIRE_MEMFD_SECRET
    value: "true"
  - name: CLOUDTASER_REQUIRE_MLOCK
    value: "true"

Layer 4: CloudTaser Operator + Wrapper

The operator's mutating webhook injects the wrapper, which fetches secrets from the EU vault directly into memfd_secret-protected memory.

# Helm values for maximum protection
operator:
  webhook:
    failurePolicy: Fail  # Reject pods if webhook is unavailable

wrapper:
  requireMemfdSecret: true
  requireMlock: true
  minProtectionScore: 70

Layer 5: eBPF Enforcement (All Vectors)

The eBPF daemonset must run on every node with full enforcement enabled.

ebpf:
  enabled: true
  enforceMode: true        # Block syscalls, not just detect
  reactiveKill: true       # SIGKILL if kprobe override unavailable
  globalPrivescDetect: true # Detect kernel module loading from any PID

The kernel must support CONFIG_BPF_KPROBE_OVERRIDE=y for synchronous blocking.

Layer 6: S3 Proxy for Data at Rest

All object storage must be encrypted client-side with keys held in the EU vault.

annotations:
  cloudtaser.io/s3-proxy: "true"
  cloudtaser.io/s3-proxy-transit-key: "eu-data-key"
  cloudtaser.io/s3-proxy-transit-mount: "transit"

The Vault Transit engine holds the Key Encryption Key (KEK). Per-object Data Encryption Keys (DEKs) are generated, used, and discarded in memory. The cloud provider stores only AES-256-GCM ciphertext.

Layer 7: Network Isolation

Restrict vault access to CloudTaser-injected pods only.

cloudtaser netpol --vault-address https://vault.eu.example.com \
  --vault-cidr 10.0.0.0/24 \
  --namespace production

---

Infrastructure Costs

Ballpark monthly costs for an ultimate protection deployment running a regulated workload (e.g., banking back-office, government identity service) on a single 3-node Kubernetes cluster in an EU region.

Compute — Confidential Kubernetes Cluster

AKS (Cheapest)GKEEKS

Azure charges no premium for confidential VMs — DCasv5 series costs the same as standard Dasv5.

Component	Spec	Monthly Cost
AKS control plane	Free tier or Standard ($0.10/hr)	€0–70
3x Confidential VMs	Standard_DC8as_v5 (8 vCPU, 32 GB), SEV-SNP	~€750
Managed disks	3x 128 GB Premium SSD	~€60
Load Balancer	Standard	~€20
Subtotal		~€830–900/mo

Confidential computing premium on Azure: 0%. Intel TDX also available via DCesv5 series at similar pricing.

Component	Spec	Monthly Cost
GKE control plane (Standard)	Zonal or regional	~€70
3x Confidential Nodes	n2d-standard-8 (8 vCPU, 32 GB), SEV-SNP	~€830
Persistent disks	3x 100 GB SSD	~€50
Cloud NAT + Load Balancer	For vault connectivity	~€50
Subtotal		~€1,000/mo

Confidential computing premium on GKE: ~5–10% over standard n2d instances.

AWS supports AMD SEV-SNP on m6a/r6a/c6a instances with a flat 10% surcharge.

Component	Spec	Monthly Cost
EKS control plane		~€70
3x Worker nodes	m6a.2xlarge (8 vCPU, 32 GB), SEV-SNP	~€990
EBS volumes	3x 100 GB gp3	~€25
NAT Gateway + ALB		~€80
Subtotal		~€1,165/mo

Confidential computing premium on EKS: exactly 10%. Alternatively, Nitro Enclaves are available at no extra cost for isolated processing.

Vault — EU-Hosted OpenBao HA Cluster

Component	Spec	Monthly Cost
3x VM instances	e2-standard-2 (2 vCPU, 8 GB) in europe-west4	~€150
3x SSD persistent disks	50 GB each for Raft storage	~€30
Cloud KMS key	Auto-unseal (HSM-backed)	~€1 + usage
Private connectivity	VPC peering / Private Service Connect	~€10
Subtotal		~€190/mo

Cloud HSM for auto-unseal

Cloud KMS with HSM protection level is sufficient for most banks. Full dedicated HSM (AWS CloudHSM at ~€1,150/mo, Azure Managed HSM at ~€3,400/mo) is an option but rarely required unless mandated by your specific regulatory framework.

CloudTaser Components

Component	Resources per Instance	Monthly Cost
Operator	50m CPU, 64 Mi memory (1 replica)	Negligible (runs on existing nodes)
eBPF Daemonset	100m CPU, 128 Mi per node (3 nodes)	Negligible
Wrapper overhead	~10m CPU, ~16 Mi per injected pod	Negligible
S3 Proxy sidecar	50m CPU, 64 Mi per pod with S3	Negligible

CloudTaser itself adds minimal resource overhead. The cost is in the infrastructure it requires, not in the software.

Total Cost Estimate

Tier	What You Get	Monthly Cost
Full Ultimate (AKS Confidential + OpenBao HA)	All 7 layers. Hypervisor gap closed. Hard guarantee. No confidential computing premium.	~€1,020–1,090/mo
Full Ultimate (GKE Confidential + OpenBao HA)	All 7 layers. Hypervisor gap closed. Hard guarantee.	~€1,190/mo
Full Ultimate (EKS SEV-SNP + OpenBao HA)	All 7 layers. Hypervisor gap closed. Hard guarantee.	~€1,355/mo
Software Complete (Standard nodes + OpenBao HA)	6 of 7 layers. Hypervisor gap open. Strong guarantee against everything except physical memory inspection.	~€700–900/mo

Context: What banks already spend

A typical EU bank running regulated workloads on managed Kubernetes spends €10,000–50,000/mo on infrastructure. CloudTaser's ultimate protection adds approximately €200–400/mo in incremental costs over a standard cluster (the confidential computing premium + vault cluster). On Azure, confidential VMs cost the same as standard — the only incremental cost is the vault cluster (~€190/mo).

---

Protection Score: 105/105

With all seven layers active, the deployment achieves the maximum possible protection score:

[cloudtaser-wrapper] Protection score: 105/105
[cloudtaser-wrapper]   memfd_secret:             OK  (+15)
[cloudtaser-wrapper]   mlock:                    OK  (+10)
[cloudtaser-wrapper]   madv_dontdump:            OK  (+10)
[cloudtaser-wrapper]   pr_set_dumpable:          OK  (+10)
[cloudtaser-wrapper]   token_protected:          OK  (+10)
[cloudtaser-wrapper]   ebpf_connected:           OK  (+10)
[cloudtaser-wrapper]   kprobes_active:           OK  (+10)
[cloudtaser-wrapper]   ld_preload_active:        OK  (+10)
[cloudtaser-wrapper]   confidential_computing:   OK  (+20)

---

Regulatory Frameworks Satisfied

This configuration provides technical supplementary measures for:

Framework	Requirement	How Ultimate Protection Satisfies It
GDPR (Schrems II)	Supplementary measures against US government access	Cloud provider never holds plaintext data or keys. EU vault under EU jurisdiction. Confidential computing prevents hypervisor access.
DORA	ICT risk management for critical financial infrastructure	Full stack isolation from third-party provider. Secrets in hardware-protected memory. Runtime enforcement against all known exfiltration vectors.
NIS2	Appropriate security measures proportionate to risk	Defense in depth across 7 layers. Continuous monitoring via eBPF. Audit trail via protection score and event logging.
DNB (Dutch Central Bank)	Outsourcing guidelines for cloud usage	Technical controls ensuring the cloud provider cannot access data even under US legal compulsion.
BIO (Baseline Informatiebeveiliging Overheid)	Dutch government information security baseline	Encryption with EU-controlled keys. Memory isolation. Runtime enforcement. Audit logging.
ISO 27001	Annex A controls for cryptography, access control, operations	13+ controls directly supported (see Compliance Mapping)
SOC 2 Type II	Trust services criteria	Confidentiality, availability, and processing integrity of secrets demonstrable through protection score and audit reports
PCI DSS 4.0	Protect stored cardholder data	Card data keys in EU vault, never in cloud provider storage. Runtime enforcement prevents key exfiltration.

---

Deployment Checklist

Use this checklist to verify all seven layers are active:

• [ ] Vault: OpenBao HA cluster running in EU region, operated by EU entity
• [ ] Vault: Auto-unseal configured with Cloud KMS (HSM protection level)
• [ ] Vault: Private network connectivity from K8s cluster (no public endpoint)
• [ ] Vault: Transit engine enabled with encryption key for S3 proxy
• [ ] Compute: Confidential computing nodes enabled (AMD SEV-SNP or Intel TDX)
• [ ] Compute: Linux 5.14+ kernel on all nodes
• [ ] Compute: CONFIG_BPF_KPROBE_OVERRIDE=y in kernel config
• [ ] Operator: Installed with webhook.failurePolicy: Fail
• [ ] Wrapper: CLOUDTASER_REQUIRE_MEMFD_SECRET=true
• [ ] Wrapper: CLOUDTASER_REQUIRE_MLOCK=true
• [ ] Wrapper: CLOUDTASER_MIN_PROTECTION_SCORE=70 (or 105 once all features ship)
• [ ] eBPF: Daemonset running on all nodes
• [ ] eBPF: ENFORCE_MODE=true and REACTIVE_KILL=true
• [ ] eBPF: GLOBAL_PRIVESC_DETECT=true
• [ ] S3 Proxy: Enabled for all workloads with object storage access
• [ ] S3 Proxy: Transit key configured and accessible
• [ ] Network: NetworkPolicies restricting vault access to CloudTaser pods only
• [ ] Monitoring: Prometheus alerts on cloudtaser_protection_score < 70
• [ ] Audit: Regular cloudtaser audit runs with JSON output to SIEM

---

What Remains After Ultimate Protection

With all seven layers active, the residual risk surface is:

Residual Risk	Probability	Mitigation
Zero-day in AMD SEV-SNP / Intel TDX firmware	Very low	Monitor CVEs, apply firmware updates, diversify CPU vendors across clusters
Side-channel attacks (Spectre/Meltdown variants)	Low	Kernel mitigations enabled by default on modern distributions; verified by protection score CPU mitigation check
Application logic that intentionally logs secrets	Medium	Code review, eBPF content matching detects known secret patterns in network/file writes
Insider at the EU vault operator	Low	RBAC, audit logging, separation of duties, HSM-backed unseal keys
Physical access to EU data center	Very low	Data center security (ISO 27001 certified), encrypted disks, HSM-protected unseal

None of these are unique to CloudTaser — they are residual risks inherent to any computing system. CloudTaser eliminates the cloud provider and US government as threat actors, which is the specific risk that Schrems II, DORA, and NIS2 require EU organizations to address.

:octicons-arrow-right-24: Security Model | :octicons-arrow-right-24: Protection Score | :octicons-arrow-right-24: Compliance Mapping