Repository navigation
[Feature]: Investigate scoping operand ServiceAccount token mount to specific phases #10571
Description
Is there an existing issue already for this feature request/idea?
- I have searched for an existing issue, and could not find anything. I believe this is a new feature request to be evaluated.
What problem is this feature going to solve? Why should it be added?
The operand pod has its ServiceAccount token mounted for the whole pod lifetime. That token can read namespace Secrets (DB creds, TLS material, backup credentials), but we only need it during bootstrap, recovery, and backup, not during steady-state serving.
That extra surface matters when the attacker did not start with Cluster write access. A PostgreSQL extension RCE, a bad image layer, or any other in-pod compromise inherits the token regardless of what phase the pod is in. The case where the attacker already has Cluster write is a separate trust-model discussion (#10570) and is out of scope here.
Describe the solution you'd like
Scope the token mount, or its capabilities, to the phases that actually need it. Worth exploring projected tokens with short expirations, audience scoping, or moving credential fetches out of the pod entirely. Design discussion before committing to a direction.
Describe alternatives you've considered
Leaving it as is. Cheap, but doesn't address the steady-state surface.
Additional context
Came up while reviewing @kodareef5's report (sent to [email protected] on 2026-03-26) and the fixes in #10515, #10518, #10565.
Backport?
No
Are you willing to actively contribute to this feature?
Yes
Code of Conduct
- I agree to follow this project's Code of Conduct
Activity
Utkarsh-sharma47 commentedon Jul 30, 2026
Hi @mnencia,
I spent some time tracing the current operand architecture to better understand where the ServiceAccount token is actually used.
One thing I found is that the current issue description seems to assume the token is only needed during bootstrap, recovery and backup. From what I could trace, that doesn't appear to be the case today.
The instance manager (instance run) creates a controller-runtime manager and continues using the Kubernetes API throughout the lifetime of the operand. Besides startup, it continuously:
watches Cluster, Secrets and ConfigMaps,
patches Cluster status,
reconciles Database / DatabaseRole / Publication / Subscription resources,
creates Events,
manages Backup resources,
and (when enabled) interacts with the primary Lease.
Because of that, I don't think a phase-scoped token mount is implementable without a much larger architectural change that moves those responsibilities elsewhere.
After looking at a few alternatives, the most realistic hardening direction seems to be using an explicitly projected, short-lived ServiceAccount token (with automountServiceAccountToken: false), rather than trying to remove the token after bootstrap. That would reduce token exposure while preserving the current controller-runtime architecture.
I haven't prepared a patch yet, since this issue explicitly asks for design discussion first, but I'm happy to investigate or prototype whichever direction the maintainers think is most appropriate.