Beta Differentiators: Volume Shield and Wire

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.

This page is the claim boundary for beta messaging. It explains what is actually different about Volume Shield and Wire, and names the words that must stay conditional until the corresponding roadmap items close.

Preview claim discipline

CloudTaser is in Preview. Do not turn this page into an unconditional compliance guarantee. For the full sovereignty claim, the deployment still needs an EU-controlled secret store, confidential-compute or otherwise acceptable compute substrate, and the operational controls named in the Sovereign Deployment Guide and Security Model.

The short version

Volume Shield moves PVC encryption into the workload pod. The raw cloud volume, snapshot, and replication stream contain CTVS ciphertext; the DEK is in the customer's EU secret store and in the unprivileged sidecar's memory, not in Kubernetes Secrets or the provider storage service.

Wire keeps secret-store connectivity outbound-only through a blind rendezvous beacon. The beacon routes on bounded rendezvous material and relays mTLS ciphertext. It does not decrypt inner-tunnel payloads. Outer TLS and tenant authentication require relay-side keys and configuration; connection metadata remains visible.

Volume Shield differentiators

Provider storage sees ciphertext

Cloud-provider disk encryption and provider-managed KMS protect data by policy and service boundary. The provider storage service still participates in the I/O path that decrypts data for the attached node.

Volume Shield changes that boundary. The pod writes plaintext to the FUSE view, the sidecar encrypts it as CTVS chunks, and the raw PVC stores ciphertext. Snapshots and backups of the raw store inherit that ciphertext.

Use this wording:

• "The storage provider receives CTVS ciphertext."
• "The DEK is held by the customer's secret store and the Volume Shield sidecar."
• "Provider snapshots of the raw PVC are ciphertext snapshots."

Do not say:

• "No cloud provider can ever see plaintext" unless the compute, secret-store, and application-runtime preconditions are named.
• "Sovereign storage" without explaining that CloudTaser is a cryptographic overlay, not a jurisdictional change.

Keys stay out of Kubernetes

Volume Shield DEKs are keyed by namespace and PVC UID in the secret store. They are not stored in Kubernetes Secrets, etcd, Helm release state, PVC annotations, or container images.

This matters because a Kubernetes-native encryption system that stores its passphrase in a Kubernetes Secret still leaves the cluster control plane in the key path. CloudTaser's storage key path is the customer secret store to the sidecar.

Use this wording:

• "No DEK in etcd."
• "No LUKS-style passphrase in a Kubernetes Secret."
• "Per-PVC DEKs are held in the customer's secret store."

Privilege and key custody are split

The Volume Shield broker owns /dev/fuse and mount(2), but never fetches or receives DEKs. The sidecar fetches the DEK, but runs without Linux capabilities.

Component	Privilege	Key access	Claim
vs-broker	Privileged node DaemonSet	None	Can mount or deny service; cannot decrypt
vs-sidecar	CapEff=0, non-root, read-only rootfs	Per-PVC DEK in memory	Can decrypt its pod's PVC; cannot mount
Raw PVC	Provider-controlled storage	None	Stores CTVS ciphertext

Use this wording:

• "Privileged mount helper, unprivileged key holder."
• "A compromised broker can deny service, not decrypt."

Do not say "no privileged component"; the broker is privileged by design.

Rollback detection: default-on, with a bounded upgrade window

Trusted freshness mode anchors ciphertext state in the secret store. With freshness enabled and bootstrapped, rollback/replay and header-strip plaintext injection fail closed.

The founder approved default-on trusted freshness on July 6, 2026, and the question closed once the populated-volume bootstrap question was resolved by volume-scoped baseline gating (cloudtaser-wrapper#167): a bounded trust-on-first-use (TOFU) window for the specific cohort of pre-existing populated volumes, closed by a one-time operator-run graduation migration. External copy may now say:

• "Trusted freshness (vault-attested rollback detection) is on by default."
• "New installs, and volumes that were empty at first mount, get rollback/replay detection from birth — no configuration required."
• "Existing volumes upgrading into default-on freshness get a bounded trust-on-first-use window, closed by a one-time, auditable migration step."

It must not say:

• "There is a freshness opt-out." There is none: current wrapper releases refuse local and disabled freshness modes at mount setup.
• "Rollback detection applies uniformly and retroactively the instant you upgrade." Populated volumes with no prior freshness state get the TOFU window described above, not instant full protection, until graduated.
• "Per-path freshness is compatible with ClickHouse, Prometheus TSDB, or VictoriaMetrics." Those workloads are unsupported on Volume Shield volumes for now; there is no opt-out.

For the workload boundary and current operations guidance, see the Volume Shield Threat Model, the configuration reference's upgrade cohorts, and Volume Shield Troubleshooting.

Wire differentiators

Blind rendezvous, not an identity relay

The beacon matches port and broker connections by bounded rendezvous material, then relays bytes. TLS terminates at the port and broker, not at the beacon.

The beacon must never become:

• A customer identity database.
• A cluster inventory.
• A key store.
• A port-broker payload metadata store.
• A durable session directory.

Use this wording:

• "Blind rendezvous relay."
• "Inner-tunnel payload keys stay at the endpoints; relay-side TLS and tenant keys require separate custody."
• "The relay can route the connection, but it cannot tell what secret, pod, tenant, or vault path is inside the tunnel."

Do not say "the relay sees nothing." It sees operational metadata such as TCP source addresses, timing, byte counts, and bounded rendezvous keys. The point is that it cannot decrypt or identify the tunnel contents.

Customer-operated production relay

Production deployments operate their own beacon. That keeps even the bounded relay metadata inside the customer's tenancy. Customers choose their relay explicitly. The public CloudTaser beacon is demo only; customer and pilot enrollment are unavailable.

Use this wording:

• "The production beacon runs in your tenancy."
• "No third party sits in the production metadata path."
• "The public CloudTaser beacon is demo only; customer pilots need their own relay."

For the full relay boundary, see the Beacon Trust Model.

Buyer comparison rows

Buyer question	Conventional pattern	CloudTaser beta answer
Can the storage provider decrypt my PVC snapshot?	Provider-managed volume encryption often decrypts inside the provider I/O path.	Volume Shield stores CTVS ciphertext on the raw PVC; the DEK is outside provider storage.
Are my disk keys in Kubernetes?	Many Kubernetes-native encryption setups put passphrases or wrapped keys in Kubernetes Secrets.	Volume Shield DEKs are not in Kubernetes Secrets, etcd, Helm state, or annotations.
Does the privileged mount process hold the key?	Privilege and key custody are often collapsed.	The broker mounts; the sidecar holds the DEK with CapEff=0.
Can the relay identify tenants or sessions?	Many relays are identity-aware control planes or service directories.	Wire's beacon is blind rendezvous: no identity DB, keys, plaintext, or durable sessions.
Do you detect storage rollback?	Integrity alone accepts old authentic bytes.	Trusted freshness is on by default; rollback/replay detection is immediate for new and already-tracked volumes, and applies to upgrade-cohort volumes once a one-time graduation migration closes their TOFU window.

Copy block

Use this for website, sales one-pagers, and analyst briefings:

CloudTaser is different because the cloud provider is not merely contractually outside the key path; it is technically outside the key path. Volume Shield encrypts PVC bytes in the pod before they reach provider storage, with DEKs held in the customer's EU secret store and an unprivileged sidecar. Wire connects the secret store to the cluster through a blind, customer-operated beacon that relays mTLS ciphertext without a customer identity database, payload keys, plaintext, or durable session state.

Add this guardrail nearby:

Trusted freshness (vault-attested rollback detection) is on by default for new CloudTaser installs. Volumes upgrading from a prior release get a bounded trust-on-first-use window until a one-time, auditable migration step graduates them to full enforcement.