Skip to content

Security: ezgamehost/celld-operator

Security

SECURITY.md

Security Policy

Reporting a vulnerability

Please report suspected vulnerabilities privately via GitHub private vulnerability reporting. Do not open a public issue for security reports. We aim to acknowledge reports within a week.

Supported versions

Only the latest release receives security fixes. This mirrors the policy of celld itself, whose alpha releases are fixed at head only — pinning an old operator against a new celld (or the reverse) is unsupported.

Scope notes for operators of this operator

Two properties of the underlying system are worth restating when assessing exposure:

  • Bucket credentials are fleet-admin authority. Anyone holding a fleet's object-store credentials controls that fleet: deployments, cell state, ownership records. Scope one credential per fleet to that fleet's prefix, and rotate on suspicion of disclosure. The operator reads these credentials (for config-hash rotation tracking and deploy-pointer tracking) but never logs or re-exports them.
  • celld's internal listener (:8081) is unauthenticated upstream. The operator fences it with NetworkPolicy and (where Istio is present) AuthorizationPolicy; weakening either is equivalent to granting cell eviction and shutdown rights to whatever can reach the pod network.
  • celld itself is not safe for hostile multi-tenant use; the isolation model is fleet-per-application. See docs/celld-behaviors.md (F3) before hosting untrusted code.

There aren't any published security advisories