Brokerium

Trust

Security

Brokerium has administrative access to your Kafka clusters. This page describes how that access is protected.

Users, roles and sessions

  • Local users with argon2id password hashes and one of three roles: viewer, operator, admin.
  • Sessions are random tokens stored as SHA-256 hashes, sent as an HttpOnly cookie for the dashboard or as a bearer token for scripts. A new password or a disabled account ends the user’s other sessions.
  • Repeated failed logins for the same user and address are refused for a growing period, and unknown usernames take as long to reject as known ones.
  • The dashboard is served with a strict Content-Security-Policy, and every request that changes something must carry a custom header that browsers do not send across sites.

Credentials of clusters

Passwords, client keys, cloud keys, tokens and kubeconfigs are sealed with AES-256-GCM using the server’s secret key and are never returned by the API.

Agents

  • An agent enrolls with a one-time join token that also pins the server’s certificate authority, so a token cannot be replayed against another server.
  • Afterwards the agent connects out to the server with mutual TLS 1.3. No inbound port is opened on Kafka hosts.
  • The agent runs a closed set of typed commands. There is no shell and no arbitrary file access. Kafka releases are downloaded from Apache and checked against the published SHA-512.

Supply chain

Release binaries come with SHA256SUMS and an SPDX SBOM. Continuous integration runs govulncheck, golangci-lint with the gosec rules and dependency license checks.

Security review

The review of 0.1.0 lists the findings, their fixes and the accepted risks.

Reporting a vulnerability

Do not open a public issue. Report privately through GitHub or write to [email protected]. Reports are acknowledged within three business days.