Skip to content

Managed-Service Coverage

CloudTaser protects the secrets your application uses and the objects your application writes to S3-compatible storage. If your workload talks to other managed services -- RDS, BigQuery, Redshift, Pub/Sub, Kinesis, DynamoDB, Redis, Elasticsearch, Snowflake, Kafka -- that data is outside CloudTaser's scope and remains subject to the same sovereignty analysis you ran before. The provider can read it unless you encrypt it client-side before sending.

This page draws the exact perimeter so you can build a realistic sovereignty plan -- not a marketing story -- for your architecture.

Schrems II on a hyperscaler is a per-service audit

A full Schrems II supplementary-measures story on an AWS / GCP / Azure -hosted architecture requires you to audit every managed service your workload talks to, not only the secrets layer. CloudTaser closes two of those services end-to-end (secrets, S3-compatible blob) and helps you close a third with trade-offs (PostgreSQL/MySQL via the DB proxy). Everything else remains yours to close or yours to accept.

Coverage table

Legend:

  • Covered -- CloudTaser provides end-to-end client-side encryption with keys in your EU OpenBao; the provider never sees plaintext.
  • Proxy, with trade-offs -- CloudTaser ships a proxy, but the encrypted data loses some operators (see DB Proxy Searchability).
  • Out of scope -- CloudTaser does not cover this service; plaintext is visible to the provider unless you encrypt it in your application.
  • N/A -- the service is irrelevant because CloudTaser replaces it entirely.
Service Category Covered? Alternative path Notes
S3 / GCS / Azure Blob / R2 / MinIO / Wasabi Object storage Covered cloudtaser-s3-proxy Client-side envelope encryption; provider stores ciphertext. Byte-addressable range reads preserved.
Self-hosted PostgreSQL / MySQL on K8s Self-managed relational Proxy, with trade-offs cloudtaser-db-proxy Random AES-GCM + optional blind indexes. See searchability guide.
RDS PostgreSQL / RDS MySQL / Aurora (both flavours) Managed relational Proxy, with trade-offs cloudtaser-db-proxy Same proxy; the EU-hosted KEK never leaves OpenBao.
Cloud SQL PostgreSQL / Cloud SQL MySQL / AlloyDB Managed relational Proxy, with trade-offs cloudtaser-db-proxy Same proxy.
Azure Database for PostgreSQL / for MySQL Managed relational Proxy, with trade-offs cloudtaser-db-proxy Same proxy.
MariaDB (self / managed) Managed relational Proxy, with trade-offs (untested in CI) cloudtaser-db-proxy with TYPE=mysql Wire-compatible with MySQL; file an issue for certified support.
MongoDB Atlas / DocumentDB / Cosmos DB Mongo API Managed document Out of scope Application-layer field-level encryption (e.g. MongoDB CSFLE) A CloudTaser-style wire proxy is a roadmap item; open an issue on cloudtaser/cloudtaser-db-proxy if this is blocking.
DynamoDB Managed key-value Out of scope AWS SDK client-side FLE, or rebuild on PG with the DB proxy AWS-proprietary API; wire-protocol proxy isn't a fit.
Cosmos DB (SQL/Table/Graph APIs) Managed multi-model Out of scope Application-layer encryption before write Same reasoning as DynamoDB.
ElastiCache Redis / MemoryStore Redis / Azure Cache for Redis / Upstash Managed KV / cache Out of scope Encrypt in the application before SET, decrypt after GET A proxy is technically possible; not on roadmap because the client-library pattern is well-established.
Elasticsearch / OpenSearch / CloudSearch / Meilisearch Cloud Managed search Out of scope Self-host the search engine on sovereign substrate Search indexes are plaintext by design; see searchability guide §full-text search for the honest discussion.
BigQuery / Redshift / Snowflake / Databricks / Synapse Managed analytics warehouses Out of scope Client-side encrypt before load; or host the warehouse on sovereign substrate Analytics warehouses exist to compute over your data; encrypting everything at the column level defeats their purpose.
Kafka / MSK / Confluent Cloud / Event Hubs / Pub/Sub / Kinesis / Kinesis Data Streams Managed streaming Out of scope Producer-side encryption; optional schema-registry envelope-encryption pattern Message payloads are opaque to the broker; encryption is the producer/consumer's responsibility.
S3 Athena / Redshift Spectrum / BigQuery external / Trino / Presto Query engines over storage Out of scope for the engine Encryption is a property of the underlying storage layer If the storage is S3 + our proxy, the engine sees ciphertext and fails the query -- this is usually not what you want.
AWS Secrets Manager / GCP Secret Manager / Azure Key Vault / SSM Parameter Store Managed secret store N/A Replaced by OpenBao CloudTaser's entire flow assumes secrets live in your EU-hosted OpenBao. Do not put new secrets in the provider's secret manager.
KMS (AWS) / Cloud KMS (GCP) / Azure Key Vault KMS Managed KMS N/A Replaced by OpenBao Transit The KEK lives in OpenBao. CloudTaser never calls provider KMS for customer keys.
Lambda / Cloud Functions / Azure Functions / Cloud Run / App Runner Serverless compute Limited The wrapper works in-principle in container-FaaS (Cloud Run, App Runner) but is not shipped as a packaged FaaS runtime today For true FaaS (Lambda, Cloud Functions), inject the wrapper at the build step and treat the FaaS runtime as a container host. No operator-side admission webhook runs there, so the injection story is hand-rolled per-function. Roadmap.
CloudFront / Cloud CDN / Azure Front Door / Cloudflare CDN Managed CDN N/A CDN terminates TLS against public-facing traffic; sovereignty is irrelevant at the CDN layer for non-sensitive static content. For sensitive responses, don't cache on the CDN.
Load balancers (ALB/NLB, GCLB, Azure LB) Managed L4/L7 N/A Same reasoning -- LBs terminate TLS but don't persist customer data; the application payload is the concern and CloudTaser covers that via the secrets + S3 + DB layer.
Managed Kubernetes (EKS / GKE / AKS / OKE) Managed control plane Partial cloudtaser-operator runs inside your cluster; secrets never hit etcd; apiserver memory sovereignty requires confidential-compute nodes (sovereign guide) K8s metadata (pod names, annotations, events) is visible to the cloud provider's control plane. Do not put secret material in pod annotations, env vars, or labels.
Container registries (ECR / GAR / ACR / GHCR / Harbor) Managed registry Out of scope for registry contents Sign your images (Cosign) and enforce signature at admission; images themselves are not "data" in the GDPR sense but the build-pipeline integrity matters See Supply-Chain Evidence and admission.enforceSignature.
Object versioning / snapshots / backups (EBS snapshots, RDS snapshots, S3 versioning) Managed storage primitives Depends on underlying For S3 via the proxy: ciphertext; snapshots carry ciphertext. For RDS: ciphertext in encrypted columns + plaintext elsewhere. Audit your snapshot/backup destinations; a "sovereign" application feeding snapshots to a US-region backup vault breaks the story.

Why this matters for the sovereignty claim

CloudTaser's honest claim -- the one that survives a Schrems II audit -- is:

Your secrets (API keys, DB passwords, JWTs, TLS private keys) never touch the US cloud provider's control plane. They go from your EU-hosted OpenBao directly into the pod's protected memory, and the provider cannot read them under compulsion, subpoena, or DBA access.

Your objects in S3-compatible blob storage are client-side-encrypted with keys held in that same EU OpenBao. The provider stores ciphertext only.

Your rows in a PostgreSQL or MySQL database can be client-side-encrypted at the column level via the CloudTaser DB proxy, with the trade-offs documented for query operators on encrypted columns.

Everything else your application sends to a managed service is out of CloudTaser's scope. The provider sees:

  • Rows in a DynamoDB table -- plaintext
  • Documents in MongoDB Atlas -- plaintext (unless you've integrated MongoDB CSFLE at the application layer)
  • Messages in Pub/Sub, Kafka, Kinesis -- plaintext (unless the producer encrypts)
  • Documents in Elasticsearch -- plaintext by necessity
  • Rows loaded into BigQuery / Redshift / Snowflake -- plaintext
  • Cache values in Redis / ElastiCache -- plaintext

If any of these contain regulated PII, CloudTaser does not close the sovereignty gap for that dataflow. You close it by:

  1. Replacing the managed service with a sovereign-substrate deployment (self-hosted on the same VM pool as OpenBao, or on an EU sovereign cloud), or
  2. Encrypting at the application layer before sending (library-based FLE for MongoDB; producer-side AES-GCM for Kafka/Pub/Sub; application-side for Redis), or
  3. Explicitly accepting that the dataflow is not sovereign and documenting the trade-off in your risk register.

Option 3 is legitimate -- not every byte in your architecture needs sovereign-grade protection. A transient session cookie in Redis is different from a customer's medical record. But that judgement has to be made and documented, not assumed away by the marketing of a product.

Paint the picture honestly

The CloudTaser deployment that survives regulator scrutiny looks like this:

User → [EU LB] → [EKS/GKE/AKS in EU] → Pod (wrapper injected)
                                          ├── secret fetch → EU OpenBao (via CloudTaser beacon)
                                          ├── object write → S3 via cloudtaser-s3-proxy → ciphertext in S3
                                          ├── SELECT/INSERT → cloudtaser-db-proxy → ciphertext columns in RDS
                                          ├── SET cache → Redis → PLAINTEXT (out of scope)
                                          ├── PUBLISH → Kafka → PLAINTEXT (out of scope)
                                          ├── INDEX doc → Elasticsearch → PLAINTEXT (out of scope)
                                          └── LOAD → BigQuery → PLAINTEXT (out of scope)

A credible sovereignty posture requires each of those arrows to land in a sovereign-covered box, or to be explicitly scoped out with an "acceptable plaintext" justification. The arrows in bold (OpenBao, S3 proxy, DB proxy) are the ones CloudTaser draws for you. The others are yours.

The right question to ask during design review is not "do we run CloudTaser?" but "for each managed service in our architecture, what is the sovereignty story?" -- with a per-service answer. CloudTaser's job is to make three of those answers trivially strong; the rest is honest architecture work.

What's on the roadmap

We're tracking the following gaps based on customer demand:

  • MongoDB wire-protocol proxy -- the most-asked next target after PostgreSQL/MySQL. Tracker: cloudtaser/cloudtaser-db-proxy issues.
  • Kafka / Pub/Sub / Kinesis producer-side envelope-encryption SDK -- a thin wrapper around standard schema-registry flows, with keys in OpenBao Transit. Scope TBD.
  • FaaS-runtime-integrated wrapper -- shipped as a Lambda layer / Cloud Functions extension / Cloud Run init container. Today the wrapper works in FaaS but requires hand-rolled per-function wiring.
  • Self-hosted FTS engine templates -- opinionated sovereign-substrate Elasticsearch / Meilisearch deployments for customers who need full-text search on PII.

Each of these is a scope decision -- not a product promise -- because the design trade-offs are different per service. If your deployment is blocked on one, file an issue and we'll scope it in the open.