[Feature]: Authenticate operator calls to the instance manager #10941

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 instance manager's remote webserver (the status port) exposes endpoints that trigger real operations: starting and stopping a backup, archiving a partial WAL, running pg_controldata, and replacing the running instance manager binary. Today none of these endpoints authenticate the caller, so any process that can reach a pod on the status port can invoke them, including replacing the instance manager binary. We want only the operator to be able to call these sensitive endpoints.

Describe the solution you'd like

The operator should prove its identity to the instance manager before the instance manager honors a sensitive request. The operator holds a private key that no one else has, and the instance manager learns, through the cluster status, which key to expect. Requests that do not prove possession of that key are rejected, while the liveness, readiness, startup, and status endpoints stay open because the kubelet and the API server proxy need them without a client certificate.

The transition has to be graceful: when the operator restarts and starts presenting a new identity, the instance manager should treat the brief window before it learns the new identity as temporary and let callers retry, rather than permanently failing an in-flight backup.

Describe alternatives you've considered

A shared bearer token distributed via a Secret would require provisioning, mounting, and rotating the secret on every pod, and a leaked token grants access until it is rotated. Requiring a full CA-verified client certificate chain would mean managing another CA and certificate lifecycle for what is effectively a single trusted caller. Pinning the operator's public key avoids both the shared-secret distribution problem and the extra CA machinery.

Additional context

Implemented in #10579. Sits in the same attack-surface area as #10570 and #10571.

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