Security Model
Zen Mesh is designed for security-critical webhook delivery. Every internal path uses strong encryption, and the control plane never sees event payloads.
Trust Chain
Trust originates from enrollment, never from configuration:
- You generate an enrollment bundle in the dashboard
- The bundle is applied to your cluster
- zen-agent uses the bundle to prove identity to the control plane
- mTLS certificates are issued via cert-manager with SPIFFE URI SAN identity (SPIRE/SPIFFE auto-rotation is planned)
- All subsequent communication uses certificate-based identity
No manual API keys, no shared secrets, no IP allowlists. Identity is cryptographic and short-lived.
Encryption Layers
| Layer | Protocol | Purpose |
|---|---|---|
| Source → Ingester | TLS 1.3 | Encrypt events in transit from webhook sources |
| Ingester → Egress | mTLS | Mutual authentication between data plane and edge |
| Egress → Target | mTLS | Secure delivery to your private services |
| Control Plane ↔ Agent | mTLS | Enrollment and config sync |
| Secrets at Rest | age encryption | Zero-knowledge storage via zen-lock |
HMAC Integrity Protection
Every event delivered through the data plane includes an HMAC-SHA256 signature. This provides:
- Tamper protection: Any modification invalidates the signature
- Source authentication: Only sources with the shared HMAC key can produce valid signatures
- Freshness verification: Timestamp and nonce in signed metadata prevent replay of captured messages
Duplicate event detection and rejection is handled by the idempotency layer (independent of HMAC).
SPIFFE Workload Identity
Every component gets a SPIFFE ID embedded in its mTLS certificate (via URI SAN):
- General mTLS certificate rotation uses cert-manager auto-renewal (active)
- SPIRE-based SVID issuance and rotation is planned (tracked as TD-011)
- Access policies are expressed in terms of SPIFFE identities
RBAC
Four levels of role-based access control:
| Role | Scope |
|---|---|
| Owner | Full access to tenant, including billing and user management |
| Admin | Manage clusters, destinations, adapters |
| Editor | Create and modify destinations, view deliveries |
| Viewer | Read-only access to dashboards and delivery logs |
SSO integration available for enterprise plans.
Zero-Knowledge Secrets
Sensitive material (enrollment credentials, HMAC keys, mTLS certs) is managed by zen-lock:
- Only ciphertext is stored in Kubernetes CRDs
- Decryption happens in a mutating webhook at pod start time
- Secrets exist as ephemeral K8s Secrets, cleaned up after use
- API server and etcd never see plaintext
Audit Trail
Every administrative action and delivery event is logged with tamper-detection via audit hash chains.