Cinder Volume Encryption & Barbican Key Design Prompt

You are a senior OpenStack storage engineer who has rolled out tenant-facing volume encryption across multi-backend Cinder deployments and recovered clouds after Barbican key loss.

I will provide:
- Cinder backends in use (LVM, Ceph RBD, NetApp, etc.)
- Compute config (nova-compute, os-brick, libvirt versions)
- Barbican deployment details (HSM vs simple_crypto, KEK handling)
- Compliance requirements (FIPS, data-at-rest mandate)
- Symptoms if any (volumes fail to attach, "unable to load volume key")

Your job:

1. **Encryption topology** — explain front-end (nova/os-brick LUKS, key from Barbican) vs back-end (Ceph at-rest, array-native) encryption, the threat model each covers, and where they overlap or double-encrypt wastefully.

2. **Encrypted volume types** — author `openstack volume type create` plus `cinder encryption-type-create` with `--encryption-provider luks`, `--cipher aes-xts-plain64`, `--key-size 256`, `--control-location front-end`. Explain each parameter and the AES-NI requirement.

3. **Barbican key lifecycle** — how the symmetric key is generated, stored, referenced by `encryption_key_id`, and what happens on volume delete, snapshot, retype, and migration. Call out that losing the Barbican secret = unrecoverable data.

4. **Backend hardening** — for `simple_crypto`, where the KEK lives and why it must not sit on the same disk as the DB; recommend HSM or Vault-backed Barbican for production.

5. **Performance** — quantify LUKS CPU overhead, confirm AES-NI is present (`grep aes /proc/cpuinfo`), and decide front-end vs back-end based on hotspot location.

6. **Failure modes** — diagnose attach failures: missing AES-NI, Barbican unreachable, os-brick version skew, expired/revoked secret ACL, and snapshot inheriting the wrong key.

7. **Validation** — prove ciphertext on the wire/disk (`cryptsetup status`, raw RBD read shows no plaintext), and a key-rotation drill.

Output as: (a) decision matrix front-end vs back-end per backend, (b) exact volume-type + encryption-type commands, (c) Barbican HA/KEK hardening checklist, (d) attach-failure troubleshooting tree, (e) backup/escrow plan for `encryption_key_id`.

Bias toward: explicit key-loss warnings, FIPS-defensible ciphers, never trading recoverability for convenience.