Ultimate Protection

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.

Identity and store-login boundary

Direct Kubernetes-auth store login authenticates a ServiceAccount and namespace, not the injected wrapper or Deployment. A pod creator using that identity, or node root stealing its JWT, can log in separately and read the role's allowed records. Use one workload per identity, exact-record policies and restricted workload creation. Exec/memory controls do not block that raw login. This limit remains unresolved; see the Security Model. One workload per identity applies on both direct and Port paths. Denial of a second same-identity workload on Port has not been established.

Deployment considerations for reducing provider access to secrets and data. These layers do not establish immunity to legal compulsion, arbitrary guest-kernel code, raw direct store login or disclosure by authorized applications.

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

These layers address specific access paths. Their availability and effect require evidence from the exact deployment; the identity, application and kernel limits above remain:

Access Path	Control and Limit	Evidence Required
etcd / K8s Secrets API	Delivery creates no Kubernetes Secret for the value	Check API objects for the tested value; application output is separate
Disk / swap / core dumps	mlock, MADV_DONTDUMP and non-dumpability cover wrapper-managed memory; application copies are separate	Verify runtime/host policy; no blanket disk/swap absence claim
/proc/PID/mem, /proc/PID/environ	Covered external reads require active enforcement; child environment copies can exist	Verify deployed vector states and delivery mode
ptrace / process_vm_readv	Coverage and synchronous denial depend on the actual hook and vector	Verify each required vector; reactive kill can follow disclosure
Kernel module injection	eBPF detects init_module / finit_module + reactive kill	Detection + response
Kernel direct memory map	memfd_secret removes a direct-map alias, not arbitrary guest-kernel access	Kernel primitive on supported nodes; not hardware isolation
Hypervisor memory inspection	Confidential compute can add a hardware boundary	Independently verify platform support, attestation and key-release policy
Object storage (S3/GCS/Blob)	S3 proxy encrypts with EU-held keys before upload	Client-side encryption
Network exfiltration	Content checks and enforced NetworkPolicy cover particular patterns/destinations; authorised copies or encodings can escape	No general prevention guarantee
OpenBao key access	OpenBao 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 OpenBao keys)
• Ciphertext in transit it cannot decrypt (mTLS to EU OpenBao)

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 (HA)

All encryption keys and secrets must be stored in an OpenBao 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 HashiCorp 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)

Confidential compute does not qualify node protection

AKS requires a verified node configuration. Assessed stock Ubuntu and Azure Linux defaults omit bpf and are expected to refuse (assessed, not run). Actual enforcement/refusal needs live evidence. A confidential VM size or secret-memory capability does not establish readiness. See Platform Compatibility.

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 OpenBao directly into memfd_secret-protected memory.

# Helm values for maximum protection
wrapper:
  healthPort: 8199
  metrics:
    enabled: false

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 OpenBao.

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

The OpenBao 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 OpenBao access to cloudtaser-injected pods only.

cloudtaser-cli target netpol --secretstore-address https://vault.eu.example.com \
  --secretstore-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 OpenBao 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.

OpenBao . 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)	Layered design; each boundary needs deployment evidence. No absolute guarantee. No confidential computing premium.	~€1,020–1,090/mo
Full Ultimate (GKE Confidential + OpenBao HA)	Layered design; each boundary needs deployment evidence. No absolute guarantee.	~€1,190/mo
Full Ultimate (EKS SEV-SNP + OpenBao HA)	Layered design; each boundary needs deployment evidence. No absolute guarantee.	~€1,355/mo
Software Complete (Standard nodes + OpenBao HA)	Layered software controls with identity, application and guest-kernel limits; external hypervisor access remains outside the boundary.	~€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 + OpenBao cluster). On Azure, confidential VMs cost the same as standard - the only incremental cost is the OpenBao cluster (~€190/mo).

---

Protection Score: 175/175

The wrapper reports up to 175 points across 17 component checks; see the protection score reference for the canonical breakdown. This synthetic all-checks example is not a qualification of a node image or proof that every required vector is enforced:

[cloudtaser-wrapper] Protection score: 175/175
[cloudtaser-wrapper]   memfd_secret:          OK  (+15)
[cloudtaser-wrapper]   mlock:                 OK  (+10)
[cloudtaser-wrapper]   core_dump_exclusion:   OK  (+5)
[cloudtaser-wrapper]   dumpable_disabled:     OK  (+5)
[cloudtaser-wrapper]   guard_pages:           OK  (+5)
[cloudtaser-wrapper]   buffer_canary:         OK  (+5)
[cloudtaser-wrapper]   token_protected:       OK  (+10)
[cloudtaser-wrapper]   environ_scrubbed:      OK  (+5)
[cloudtaser-wrapper]   getenv_interposer:     OK  (+10)
[cloudtaser-wrapper]   ebpf_agent_connected:  OK  (+10)
[cloudtaser-wrapper]   cpu_mitigations:       OK  (+5)
[cloudtaser-wrapper]   ebpf_enforce_mode:     OK  (+15)
[cloudtaser-wrapper]   ebpf_lsm_enforce:      OK  (+15)
[cloudtaser-wrapper]   ebpf_kprobes:          OK  (+10)
[cloudtaser-wrapper]   confidential_vm:       OK  (+10)
[cloudtaser-wrapper]   vault_tls_verified:    OK  (+20)
[cloudtaser-wrapper]   broker_tls_verified:   OK  (+20)

---

Regulatory Framework Coverage

Technical control mappings, not certifications

These are technical control mappings, not certifications. CloudTaser has not completed SOC 2 or ISO 27001 audits. See Compliance Preview Status.

This configuration provides technical supplementary measures for:

Framework	Requirement	How Ultimate Protection Satisfies It
GDPR (Schrems II)	Supplementary measures against US government access	EU-controlled store and qualified confidential compute address specific boundaries; raw direct login, arbitrary guest-kernel code and authorised application output remain risks.
DORA	ICT risk management for critical financial infrastructure	Configured runtime checks cover specific paths and patterns. An authorised app can disclose copied or encoded secrets; no general prevention guarantee is established. Enforced egress policy narrows destinations but allowed channels remain
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	Covered read-path controls, subject to identity, application, kernel and compute boundaries; no immunity to legal compulsion is established.
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	Configured runtime checks cover specific paths and patterns. An authorised app can disclose copied or encoded secrets; no general prevention guarantee is established. Enforced egress policy narrows destinations but allowed channels remain

---

Deployment Checklist

Use this checklist to verify all seven layers are active:

• [ ] OpenBao: OpenBao HA cluster running in EU region, operated by EU entity
• [ ] OpenBao: Auto-unseal configured with Cloud KMS (HSM protection level)
• [ ] OpenBao: Private network connectivity from K8s cluster (no public endpoint)
• [ ] OpenBao: 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: Verify the rendered webhook uses Fail in enrolled namespaces
• [ ] Wrapper: Verify the default CLOUDTASER_REQUIRE_MEMFD_SECRET protection is active; see generated memory defaults
• [ ] Wrapper: Verify the default CLOUDTASER_REQUIRE_MLOCK protection is active; see generated memory defaults
• [ ] Wrapper: Review CLOUDTASER_MIN_PROTECTION_SCORE against the current 175-point breakdown and required checks; a numerical threshold alone does not qualify enforcement
• [ ] 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 OpenBao access to cloudtaser pods only
• [ ] Monitoring: Prometheus alerts on cloudtaser_protection_score < 70
• [ ] Audit: Regular cloudtaser-cli target 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 OpenBao 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.

Security Model | Protection Score | Compliance Mapping