Describe the desired outcome from the user's perspective
As a Zilla operator, I want to configure the vault key: as a dynamic expression derived from the Kafka message at produce time, so that each entity's data is encrypted under a unique key. Deleting that key in the KMS permanently destroys all messages for that entity without touching Kafka — enabling GDPR right-to-erasure via crypto-shredding.
Acceptance criteria
- Vault
key: supports ${...} expressions evaluated at produce time:
${message.key} — derive key name from the Kafka message key${message.headers.<name>} — derive key name from a Kafka message header value
- Resolved key name written to
zilla:key header at produce time; that stored value is used directly on consume — no re-evaluation of the expression
- Expression syntax is consistent with existing Zilla
${...} resolution used for environment variables and route parameters elsewhere in config
- Startup validation: expression syntax errors reported clearly
Additional context
Common patterns:
vault:
my-kms:
key: ${message.key} # per-entity from Kafka message key
key: ${message.headers.user-id} # per-user from application header
key: ${message.headers.tenant-id} # per-tenant isolation on shared topic
key: ${message.headers.region} # per-region data residencyTo crypto-shred all data for a given entity: delete or rotate their KMS key. All messages encrypted under that key become permanently unreadable. No Kafka messages need to be touched.
Describe the desired outcome from the user's perspective
As a Zilla operator, I want to configure the vault
key:as a dynamic expression derived from the Kafka message at produce time, so that each entity's data is encrypted under a unique key. Deleting that key in the KMS permanently destroys all messages for that entity without touching Kafka — enabling GDPR right-to-erasure via crypto-shredding.Acceptance criteria
key:supports${...}expressions evaluated at produce time:${message.key}— derive key name from the Kafka message key${message.headers.<name>}— derive key name from a Kafka message header valuezilla:keyheader at produce time; that stored value is used directly on consume — no re-evaluation of the expression${...}resolution used for environment variables and route parameters elsewhere in configAdditional context
Common patterns:
To crypto-shred all data for a given entity: delete or rotate their KMS key. All messages encrypted under that key become permanently unreadable. No Kafka messages need to be touched.