Security

This chapter helps end users install and run KalamDB with a secure baseline.

It focuses on practical deployment choices and operational controls, not implementation code.

Security Goals

A secure KalamDB deployment should provide:

• Encrypted traffic for client access and node-to-node communication.
• Strong authentication for users and services.
• Clear authorization boundaries so users only access what they are allowed to access.
• Abuse protection to reduce brute-force and traffic-flood risk.
• Reduced public exposure of sensitive operational endpoints.

Recommended Baseline

Before exposing KalamDB to real user traffic, make sure you have:

• HTTPS enabled for all client-facing access.
• A strong JWT signing secret and trusted issuer policy.
• Remote setup disabled after initial bootstrap.
• Explicit CORS origin allowlists (no wildcard origins in production).
• Request-size and message-size limits in place.
• Rate-limit protection enabled and tuned for your workload.
• Operational endpoints reachable only from trusted networks.

Transport and Certificate Safety

For most deployments:

• Terminate TLS at a trusted edge proxy or load balancer.
• Use valid certificates and monitor expiration dates.
• Keep private keys restricted and rotate certificates on a schedule.

For multi-node clusters:

• Enable mTLS for inter-node RPC.
• Use unique certificates per node.
• Keep cluster RPC ports private to internal networks.

Secrets and Identity Hygiene

• Store secrets in a secure secret manager, not in source control.
• Rotate JWT secrets with a planned window for token rollover.
• Separate day-to-day app identities from admin/operator identities.
• Apply least-privilege roles for users and services.

Monitoring and Operations

Track security signals continuously:

• Authentication failures and authorization-denied spikes.
• Unusual increases in bans, throttling, or connection rejections.
• Cluster trust failures in multi-node environments.

Have an incident process ready:

• Rotate compromised secrets or certificates quickly.
• Disable or revoke compromised identities.
• Tighten ingress and rate limits during active attack windows.

Security Readiness Checklist

• HTTPS-only client access is enforced.
• Strong JWT secret is configured and managed securely.
• Trusted issuer policy is configured when using external identity providers.
• Setup/bootstrap exposure is restricted after initial install.
• CORS and origin controls are explicitly configured.
• Request/message limits are set to safe values.
• Rate limiting is enabled and tested.
• Logs and alerts are in place for auth and abuse patterns.
• Multi-node deployments use mTLS for inter-node RPC.

Rate Limiting

See Rate Limiting for planning and tuning guidance.