Managed Databases

The Problem

When you use a managed database (Cloud SQL, RDS, Aurora, AlloyDB, Spanner, DynamoDB, Azure SQL), the cloud provider controls every layer:

Why CMEK Doesn't Help

Customer-Managed Encryption Keys (CMEK) sound sovereign, but they aren't. The key lives in the provider's KMS (Cloud KMS, AWS KMS, Azure Key Vault). The provider's infrastructure performs the encryption/decryption. Under a CLOUD Act order, the provider can be compelled to use the key — they have the technical capability, which is all that matters legally.

Phantom's Approach: DB Proxy Sidecar

The strongest protection Phantom can offer for managed databases is application-level encryption via an injected database proxy sidecar — architecturally identical to the existing secret injection pattern:

┌─────────────────────────────────────────────────────────┐
│  Pod (injected by Phantom mutating webhook)             │
│                                                         │
│  ┌──────────────┐    ┌────────────────────────────────┐ │
│  │ App Container │    │ Phantom DB Proxy Sidecar       │ │
│  │              │───▶│  • Encrypts on write            │ │
│  │ connects to  │    │  • Decrypts on read             │ │
│  │ localhost:   │    │  • Keys from EU OpenBao         │ │
│  │ 5432/3306    │    │  • Field-level granularity      │ │
│  └──────────────┘    └──────────────┬─────────────────┘ │
│                                     │                   │
│  ┌─────────────────────────┐        │                   │
│  │ Phantom Secret Sidecar  │        │                   │
│  │ (existing)              │        │                   │
│  └─────────────────────────┘        │                   │
└─────────────────────────────────────┼───────────────────┘
                                      │ TLS
                                      ▼
                          ┌───────────────────────┐
                          │   Managed Database     │
                          │   (Cloud SQL / RDS)    │
                          │                        │
                          │   Stores CIPHERTEXT    │
                          │   Provider sees blobs  │
                          └───────────────────────┘

                          ┌───────────────────────┐
                          │   EU-Hosted OpenBao    │
                          │   (Encryption Keys)    │
                          │                        │
                          │   Outside CLOUD Act    │
                          │   jurisdiction          │
                          └───────────────────────┘

How It Works

1. Same webhook — the existing Phantom mutating admission webhook injects the DB proxy sidecar alongside the secret sidecar
2. Transparent to the app — application connects to localhost:5432 (Postgres) or localhost:3306 (MySQL). The proxy intercepts the connection.
3. Field-level encryption — configured per-table, per-column. Only sensitive fields are encrypted. Non-sensitive columns remain queryable as normal.
4. Keys from EU OpenBao — encryption keys fetched from the same EU-hosted OpenBao instance. Keys never enter cloud provider infrastructure.
5. Managed DB stores ciphertext — the cloud provider (and any CLOUD Act subpoena) gets encrypted blobs for protected fields.

Configuration Example

# Phantom DB proxy annotation on a Deployment
metadata:
  annotations:
    phantom.cloudcondom.io/db-proxy: "enabled"
    phantom.cloudcondom.io/db-target: "cloud-sql-instance:5432"
    phantom.cloudcondom.io/db-encrypt: |
      customers:
        - email          # deterministic — allows equality lookups
        - phone_number   # deterministic
        - address        # randomized — no query capability
        - tax_id         # randomized
      payments:
        - card_number    # randomized
        - bank_account   # randomized
      health_records:
        - diagnosis      # randomized
        - prescription   # randomized

Encryption Modes & Trade-offs

Not all encryption is equal. The mode determines what database operations remain possible on encrypted fields:

What Works and What Breaks

Recommended Data Classification

Not all data needs the same protection level. The practical approach is a tiered model:

Real-World Example: Financial SaaS

Consider a typical financial services application with a customers table:

Result: 4 out of 9 columns encrypted. The application continues to work normally — login lookups, plan filtering, date sorting all function. But a CLOUD Act subpoena for this table returns full_name, phone, tax_id, and address as encrypted blobs.

Alternative Approaches Compared

Prior Art & Existing Solutions

Application-level database encryption is not a new concept. Several products exist in this space:

Phantom Product Tiers

The database proxy positions Phantom as a broader data sovereignty platform, not just a secrets manager:

The Nuclear Option: Self-Managed on Confidential VMs

For maximum protection, skip managed databases entirely:

1. Run PostgreSQL / MySQL on Confidential VM nodes (AMD SEV-SNP / Intel TDX) within the cloud
2. Phantom manages all database encryption keys via EU OpenBao
3. Database TDE (Transparent Data Encryption) uses keys from OpenBao, not cloud KMS
4. Backups encrypted with keys the cloud provider cannot access
5. Memory encrypted at hardware level — hypervisor cannot inspect queries or data

You lose: automatic patching, built-in HA, managed backups, one-click replicas, connection pooling, query insights. You manage all of this yourself (or via operators like CloudNativePG, Zalando Postgres Operator).

You gain: complete data sovereignty. The cloud provider is reduced to a compute and network layer with zero visibility into your data.

CLOUD Act Subpoena Scenario

What happens when a US government agency serves a CLOUD Act order to the cloud provider for a customer's database:

Implementation Considerations

Performance Impact

Migration Strategy

1. Audit — identify sensitive columns across all tables (typically 5-15 per application)
2. Classify — assign Tier 1 (critical), Tier 2 (sensitive), or Tier 3 (operational) to each column
3. Encrypt in place — run migration that reads plaintext, encrypts via proxy, writes back. Can be done rolling.
4. Enable proxy — switch application to connect via Phantom DB proxy. No application code changes for basic mode.
5. Verify — confirm encrypted fields return ciphertext when queried directly (bypassing proxy)

Supported Databases

Key Takeaways