Feature: field-level encryption support for step.event_publish

[intel352]

Summary

step.event_publish currently publishes CloudEvents without any encryption support. For compliance-sensitive workloads (PII, PHI), field-level encryption is needed before events hit the transport layer.

Use Case

Healthcare/crisis applications need to encrypt specific fields (e.g., phone numbers, message content) within CloudEvent payloads using envelope encryption (KMS + DEK pattern) before publishing to Kinesis/SQS/Kafka. The encrypted event should conform to CloudEvents v1.0 with encryption metadata stored as extensions.

Proposed Approach

Add optional encryption config to step.event_publish:

- name: publish
  type: step.event_publish
  config:
    topic: follow-up.created
    source: chimera-api
    encryption:
      provider: kms          # or "aes", "envelope"
      key_id: "${KMS_KEY_ARN}"
      fields: [phone, message_body, responder_name]
      algorithm: AES-256-GCM

The step would:

1. Generate a per-event DEK
2. Encrypt specified fields individually (preserving event structure)
3. Store encrypted DEK + field metadata as CloudEvents extensions (encryption, keyid, encrypteddek, encryptedfields)
4. Publish the modified event

A corresponding decryption utility or step (step.event_decrypt?) would reverse the process on the consumer side.

Alternatives Considered

• Application-level encryption before step: Works but duplicates logic across every pipeline that publishes sensitive events
• Transport-level encryption (TLS/KMS on Kinesis): Encrypts in transit/at rest but not at the field level — all consumers see all fields
• Bento processor: Could use a custom Bloblang mapping, but encryption logic doesn't belong in stream transforms

Context

The modular EventBus interface and KinesisEventBus handle transport. This feature is about the pipeline step adding encryption before handing off to the EventBus.