[Docs]: Document operational implications of Cluster CRD write permissions #10570

Is there an existing issue already for your request/idea?

• I have searched for an existing issue, and could not find anything. I believe this is a new documentation enhancement to be evaluated.

What problem in the existing documentation this issue aims to solve?

Write access to a Cluster resource grants the practical capability to execute arbitrary code on the operand pod through documented and intended fields, including but not limited to:

• spec.bootstrap.initdb.postInitSQL, postInitApplicationSQL, and postInitTemplateSQL
• spec.managed.roles combined with PostgreSQL features such as COPY ... FROM PROGRAM
• Custom configuration parameters

From the operand pod, the mounted ServiceAccount enables reading namespace-scoped Secrets, including database credentials, TLS material, and backup-storage credentials.

This trust model is consistent with how comparable Kubernetes resources work and is documented in the project's self security assessment, but it is not surfaced clearly in the user-facing security documentation. We have received more than one external report framing this capability as a privilege escalation, which indicates the trust model is not visible enough to operators and security reviewers.

Describe what additions need to be done to the documentation

A "trust model" section in the user-facing security documentation that makes explicit what Cluster write capability implies in practice (database superuser on the resulting cluster, code execution on the operand pod, namespace Secret access via the mounted ServiceAccount), with RBAC guidance and worked examples for shared-namespace and multi-tenant deployments.

Describe what pages need to change in the documentation, if any

The user-facing security documentation. The self-assessment should cross-reference the new section.

Describe what pages need to be removed from the documentation, if any

N/A

Additional context

The architectural question of whether the operand pod's ServiceAccount token needs to be mounted for the full pod lifecycle, or whether it could be scoped to specific phases (bootstrap, recovery), is tracked in a separate issue.

@kodareef5 prompted this work via a report sent to [email protected] on 2026-03-26.

Backport?

Yes

Code of Conduct

• I agree to follow this project's Code of Conduct