Where cloudtaser pays for itself.

Overlapping rules on cross-border access

• PSD2 - strong customer authentication and secure payment credentials, protected from unauthorised access including the infrastructure provider.
• DORA - in November 2025, AWS, Google, and Azure were designated Critical ICT Third-Party Providers. Articles 28 and 30 require contractual data-protection provisions - but contracts alone fail under the CLOUD Act.
• GDPR Articles 44–49 - require adequate protection for cross-border transfers; the EDPB recommends client-side encryption where the provider does not hold keys.
• MiFID II / MiFIR - transaction reporting and record-keeping require protection plus auditability.

Payments API in eu-west-1

A European bank runs its payments API on AWS EKS in eu-west-1. Under DORA, AWS is now classified as a Critical ICT Third-Party Provider - the bank must demonstrate third-party risk management. Under the CLOUD Act, AWS can be compelled to hand over database credentials, transaction records, and customer payment data, regardless of the data-centre location.

The bank keeps the keys. AWS gets ciphertext.

• Database passwords and API keys are fetched from an EU-hosted OpenBao instance in Frankfurt. The wrapper's secret store delivers them into process memory - never into etcd, K8s Secrets, or disk. The wrapped application's runtime (JVM heap dumps, kernel coredumps) is governed by host policy.
• The S3 proxy encrypts transaction logs with per-object AES-256-GCM keys before they reach S3. AWS sees only ciphertext.
• eBPF monitoring provides the runtime incident detection DORA requires - 7 Prometheus metrics feed directly into existing SIEM/alerting pipelines.
• Secret store audit logs create a tamper-proof record of every secret access, satisfying DORA's third-party risk assessment requirements.
• Portable secret store + standard K8s enable the DORA-mandated exit strategy - migrate between providers without re-architecting secret management.

Full DORA compliance mapping →

Scrutiny rising across every EU jurisdiction

• BSI C5 (Germany) - required for German public-sector cloud procurement; demands demonstrated data sovereignty and EU-controlled key management.
• SecNumCloud (France) - ANSSI qualification that demands immunity from non-EU laws.
• EDPS ruling, March 2024 - the European Commission's own Microsoft 365 use was found to violate data-protection law.
• Dutch Parliament, March 2025 - motions requiring reduced US-cloud dependence and European preferential treatment in procurement.
• EC Cloud Sovereignty Framework, October 2025 - €180M tender explicitly includes key management under EU control as a sovereignty objective.

Citizen services on managed Kubernetes

A German federal agency runs citizen services on GCP GKE. BSI C5 certification requires demonstrated data sovereignty. The EDPS has already ruled the European Commission's own Microsoft 365 use illegal due to insufficient data protection. The agency needs best-in-class cloud technology without the legal exposure.

GCP keeps ciphertext. BSI keeps the keys.

• All secrets and encryption keys are stored in BSI-compliant EU infrastructure. GCP stores only ciphertext.
• Effective supplementary technical measures the EDPB recommends - satisfying both GDPR and C5 requirements simultaneously.
• SecNumCloud-compatible - the technical layer makes US-hosted infrastructure functionally immune to CLOUD Act access.
• Audit trail - every secret access is logged in the EU secret store, giving government auditors tamper-proof evidence.
• No vendor lock-in - portable secret store plus standard Kubernetes means migration if sovereignty requirements change.

EUCS compliance mapping →

Every existing approach leaks plaintext somewhere

GitOps workflows store desired state in Git and reconcile it to the cluster. This works well for manifests, but secrets create a conflict: you cannot store plaintext secrets in Git, and every workaround introduces complexity or risk.

• Sealed Secrets / SOPS - encrypt in Git, decrypt into K8s Secrets at sync time. The decrypted secret still lands in etcd as base64 - readable by anyone with cluster access.
• External Secrets Operator - syncs from an external store into K8s Secrets. The secret materialises in etcd; if the store is AWS Secrets Manager, the CLOUD Act still applies.
• Vault Agent Injector - per-pod sidecar. Avoids etcd but adds per-pod resource overhead and per-deployment configuration.
• ArgoCD Vault Plugin - renders placeholders at sync time. Still writes secrets to K8s Secrets in etcd after rendering.

Every GitOps secret solution either stores decrypted secrets in etcd, or requires per-pod sidecars with significant resource overhead.

Annotations in Git. Secrets in the EU secret store. Nothing in etcd.

Your ArgoCD Application manifests contain only cloudtaser annotations - role, secret paths, and env mapping. No encrypted blobs, no sealed secrets, no placeholder tokens, no vault addresses. The operator routes secret fetches through the P2P beacon broker, so pods need no per-workload vault config.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments-api
spec:
  template:
    metadata:
      annotations:
        cloudtaser.io/inject: "true"
        cloudtaser.io/vault-role: "payments-api"
        cloudtaser.io/secret-paths: "secret/data/payments/credentials"
        cloudtaser.io/env-map: "password=DB_PASSWORD,api_key=STRIPE_KEY"

• ArgoCD syncs normally - the mutating webhook intercepts pod creation, detects the annotations, and wraps the entrypoint. No plugins, no CRDs, no sync hooks.
• Secrets flow from EU store to process memory - kubectl get secrets shows nothing cloudtaser-related.

Admission webhooks don't care what created the pod

cloudtaser operates at the Kubernetes admission webhook level - it intercepts pod creation regardless of what created the pod. Works identically with:

• ArgoCD - Application and ApplicationSet resources.
• Flux CD - Kustomization and HelmRelease resources.
• Helm - direct helm install or GitOps-managed HelmRelease.
• kubectl apply - manual or CI/CD pipeline deployments.
• Crossplane / Terraform - infrastructure-as-code managed pods.

EU AI Act GPAI obligations

The EU AI Act's GPAI obligations took effect in August 2025. Model providers must maintain documentation about training data, comply with EU copyright law, and share information with regulators. Training large models on regulated data (patient records, financial transactions, personal data) requires protecting the entire pipeline's secrets - dataset access credentials, model weights storage keys, API keys.

Treat the training cluster like any other K8s cluster.

• ML training pipelines on Kubeflow, Argo Workflows, or Ray clusters are just K8s pods. The wrapper injects credentials from the EU secret store without application changes.
• eBPF agent monitors for credential exfiltration - critical when running untrusted model code.
• S3 proxy encrypts training datasets and model artifacts at rest with per-object keys.
• Automotive AI - NIS2 classifies connected vehicle infrastructure as critical. Backend services handling telemetry, OTA update keys, and fleet credentials have the same sovereignty requirements.