Leba is intended to run on internet-facing hosts. The default operational stance should be conservative: least privilege, explicit admin credentials, private control-plane exposure, and fail-closed routing.

Leba is written in Mako and relies on Mako ownership/free analysis for application code. The project still treats security as a process, not a slogan: native ACME, certificate writes, TLS reload, and admin mutation paths require code review, adversarial tests, and white-hat review before stronger replacement claims.

Configure role-specific credentials on every mode stats frontend before exposing it.

frontend stats
  bind 18404
  mode stats
  admin_users_file /etc/leba/admin-users.conf

admin-users.conf stores role-specific password hashes:

admin $argon2id$v=19$m=19456,t=2,p=1$SALT$HASH admin
viewer leba-kdf-v1:ITERATIONS:SALT_HEX:HASH_HEX viewer
operator leba-kdf-v1:ITERATIONS:SALT_HEX:HASH_HEX operator

New hashes use Argon2id when the linked Mako crypto backend supports it and fall back to leba-kdf-v1 otherwise. Legacy SHA-256 hashes are accepted only for compatibility.

When credentials are configured, Leba protects:

• admin dashboard
• /stats
• /metrics
• /admin/* runtime actions

Probe endpoints remain unauthenticated:

• /health
• /livez
• /readyz

Unauthenticated admin requests return 401 JSON. Authenticated users without enough role privilege receive 403.

Sample local config uses demo plaintext credentials. The Linux template uses admin_users_file with CHANGE_ME_* placeholders. leba doctor warns on placeholder/demo values and errors on malformed hashes.

Use long random passwords and store only salted, iterated hashes in production configs.

leba admin hash-password 'strong-password'

Treat the admin endpoint as a privileged control plane because it can drain, enable, disable, and reload upstream server membership.

Recommended deployment shape:

• expose only public HTTP/TCP/SIP frontend ports to the internet
• keep stats/admin ports on private interfaces behind trusted network controls
• restrict admin access with host firewall rules
• run leba doctor before restarting a production instance

Current hardening:

• raw HTTP requests larger than the configured limit are rejected with HTTP 413 before upstream forwarding
• raw HTTP request limits are configurable with request_body_limit; see LIMITS.md
• protected admin requests write audit logs with request ID, authenticated user, role, method, path, status, and outcome
• ACL denies are enforced before backend selection
• rate limits are enforced before upstream forwarding
• backend server maxconn caps fail closed when saturated
• all-drained or all-down pools fail closed instead of choosing an unavailable server
• trace headers are validated before use and forwarded upstream only after validation or regeneration

Native HTTP-01 issuance avoids nginx, certbot, and lego as required runtime dependencies. Review the following before treating it as a high-trust production certificate manager:

• P-256 account-key generation, storage path, and permissions
• ES256 JWS construction, nonce use, JWK thumbprints, and CSR encoding
• HTTP-01 token validation and challenge-file serving
• domain/path validation and traversal rejection
• certificate/key file writes and live TLS/SNI reload
• admin RBAC on issue, renew, and reload endpoints

Admin UI session cookies are signed with material from, in order:

1. state_key in defaults (preferred)
2. LEBA_SESSION_SECRET environment variable
3. an insecure local-dev default; doctor warns when neither 1 nor 2 is set

These remain open:

• white-hat review closure for native ACME/certificate paths
• configurable probe authentication policy
• broader TLS HTTP/2 accept-path hardening
• RTP/media handling