Skip to content

Volume Shield DEK Revocation and Crypto-Shredding

Use this runbook when a single encrypted PVC must become permanently unreadable: data subject erasure, tenant offboarding, breach containment, or destruction of an abandoned volume. The operation destroys the per-PVC Data Encryption Key (DEK) stored in OpenBao. Existing ciphertext, snapshots, backups, and replicas may remain as bytes, but they cannot be decrypted without that DEK.

Irreversible operation

DEK revocation is destructive. After the OpenBao metadata is deleted, the old PVC contents can be recovered only from a trusted backup that still includes the old DEK. Volume Shield does not yet support non-destructive DEK rotation without re-encrypting the volume.

Scope and prerequisites

  • Identify exactly one PVC by namespace and PVC name.
  • Use an OpenBao or Vault token that can delete metadata under cloudtaser/volumes/* and, if trusted nonce budgeting or freshness is enabled, under cloudtaser/volumeshield-state/*.
  • Quiesce the owning workload first. A running sidecar may already have initialized its cipher for the old DEK and can keep serving until the pod is terminated.
  • Keep an incident or erasure record with the PVC UID, OpenBao audit event IDs, operator, timestamp, and verification output.

1. Identify the PVC key paths

Volume Shield keys DEKs by namespace and PVC UID, not by the mutable PVC name.

NS=<namespace>
PVC=<pvc-name>

PVC_UID=$(kubectl get pvc "$PVC" -n "$NS" -o jsonpath='{.metadata.uid}')
DEK_PATH="cloudtaser/volumes/$NS/$PVC_UID"
STATE_PATH="cloudtaser/volumeshield-state/$NS/$PVC_UID"

printf 'DEK path:   %s\n' "$DEK_PATH"
printf 'State path: %s\n' "$STATE_PATH"

Confirm the PVC is annotated for Volume Shield:

kubectl get pvc "$PVC" -n "$NS" \
  -o jsonpath='{.metadata.annotations.cloudtaser\.io/encrypt-pvc}{"\n"}'

The output must be true.

2. Stop every pod that can hold the DEK

Deleting the OpenBao record prevents future DEK fetches. It does not erase a DEK already used by a live sidecar. Stop or delete every pod that mounts the PVC before treating the data as shredded.

kubectl get pods -n "$NS" -o json \
  | jq -r --arg claim "$PVC" '
      .items[]
      | select(any(.spec.volumes[]?; .persistentVolumeClaim.claimName == $claim))
      | .metadata.name
    '

Scale, suspend, or otherwise stop the owning workload through your normal controller. Examples:

kubectl scale deployment/<deployment> -n "$NS" --replicas=0
kubectl scale statefulset/<statefulset> -n "$NS" --replicas=0

If a workload is not controller-managed, delete the pod after confirming the application owner has approved the interruption:

kubectl delete pod/<pod> -n "$NS"

For immediate incident response, also consider recycling the node after pod termination if your policy requires clearing process memory beyond normal pod exit.

3. Delete the DEK metadata

For KV v2, delete the metadata entry so all versions are purged and the path is not recoverable through normal version rollback.

bao kv metadata delete "$DEK_PATH"

vault kv metadata delete "$DEK_PATH"

If your CLI is configured with a mount name instead of the logical path shown above, use the equivalent command for your mount. At the raw API level, KV v2 metadata deletion addresses the mount's /metadata/ path, not /data/.

4. Delete trusted state for that PVC

When volumeShield.nonceBudget.mode: vault or volumeShield.freshness.mode: vault is enabled, remove the associated state tree as well. This state is not the DEK, but leaving it behind can confuse audits and future PVC reuse checks.

bao kv metadata delete "$STATE_PATH" || true

vault kv metadata delete "$STATE_PATH" || true

Trusted freshness stores per-file records under:

cloudtaser/volumeshield-state/<namespace>/<pvc-uid>/files/<sha256(relpath)>

List and delete any child metadata below "$STATE_PATH/files" using your OpenBao or Vault namespace and mount conventions. Keep the command transcript in the erasure record.

5. Verify shredding

Run all checks that apply to your environment:

# The DEK must be gone.
bao kv get "$DEK_PATH"

# The DEK must be gone.
vault kv get "$DEK_PATH"

The command for your environment should fail with a not-found response.

# The workload should not be able to remount the old PVC.
kubectl scale deployment/<deployment> -n "$NS" --replicas=1
kubectl logs -n "$NS" deployment/<deployment> -c cloudtaser-vs-sidecar --tail=100

Expected result: the sidecar fails closed while fetching the DEK, the pod does not become ready, and application reads through the Volume Shield mount cannot return plaintext.

Optional raw-store checks:

  • Raw backing files should begin with the CTVS magic for encrypted data: head -c 4 <raw-file>.
  • Searching the raw backing store for known non-secret test markers should not find plaintext.
  • OpenBao audit logs should show metadata deletion for "$DEK_PATH" and, when enabled, "$STATE_PATH".

Do not copy sensitive sample data into tickets or audit records. Record command names, timestamps, object IDs, and not-found outcomes instead.

Operational effects

  • Existing cloud-provider snapshots and backups remain ciphertext-only. They are part of the erasure scope because the DEK that made them readable no longer exists in OpenBao.
  • Running pods must be terminated for immediate erasure semantics. A sidecar that already initialized a cipher may retain enough key material in process memory to serve until it exits.
  • New pods, remounts, and restarted sidecars fail closed because the DEK fetch returns not found.
  • A new PVC, or a reinitialized empty PVC with the same application purpose, must receive a new DEK. Do not reuse the deleted key path by restoring the old DEK unless this is an explicitly approved recovery action.

GDPR Article 17 mapping

Crypto-shredding is the technical erasure action for Volume Shield protected PVC data: the organization destroys the only customer-controlled key that can decrypt the provider-held ciphertext. This supports Article 17 erasure evidence for encrypted volume contents, including provider-retained snapshots and backups, when all of the following are true:

  • The target PVC was protected by Volume Shield before the relevant data was written or migrated.
  • Every DEK version at cloudtaser/volumes/<namespace>/<pvc-uid> that can decrypt retained PVC ciphertext was irreversibly deleted.
  • Running sidecars that may have held the DEK were terminated.
  • Backups that contain the old DEK are either outside the erasure set by policy or are also destroyed.
  • The audit record ties the erasure request to the PVC UID, DEK path, destroyed version set, state path, deletion timestamp, and verification result.

This page is operational guidance, not legal advice. Compliance teams should map the retained audit evidence to the organization's Article 17 procedure and backup retention policy.

Recovery options

There is no in-place recovery after a DEK is shredded. The only options are:

  • Restore from a pre-revocation trusted backup that includes the old DEK and is approved for use.
  • Recreate or reinitialize the PVC as empty data and let Volume Shield generate or receive a new DEK.
  • Restore application-level data from an independent plaintext export that is allowed under the erasure decision.

For planned, non-destructive key rotation, publish a new versioned Volume Shield DEK secret and retain old DEK versions until every still-needed file has been re-stamped or intentionally retired. Do not use this crypto-shredding runbook for ordinary rotation.