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.
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.
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.