❗ By default, the pull request is configured to backport to all release branches.

• To stop backporting this pr, remove the label: backport-requested ◀️ or add the label 'do not backport'
• To stop backporting this pr to a certain release branch, remove the specific branch label: release-x.y

/test

@sxd, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/12918936177

@sxd could you please review and merge this one?

Thank you so much for this PR! I need this feature to be allowed to deploy CloudNative-PG at my org.

Very nice! Can we get this added?

@x0ddf hi!

I haven't had time to look into this with full time but the first things that comes to my eyes is, where is the documentation and explanation for the usage of this and also all the risks that can come from a bad configuration of a security context? Something like that should explain what kind of things we can expect if something is badly configured, for example, PostgreSQL not starting because the security context define a different user from the one on the image, or that was defined previously ergo you'll see permissions issue.

Also, you're touching the pgbouncer one, that should be handled using the PodTemplate not using the options from the cluster.

On the proposal we allow to change the Security Context even on running pods, should we allow that?

Just to finish a quick review, please, this is lacking some test and E2E tests.

Regards,

@sxd hi!

I haven't had time to look into this with full time but the first things that comes to my eyes is, where is the documentation and explanation for the usage of this and also all the risks that can come from a bad configuration of a security context? Something like that should explain what kind of things we can expect if something is badly configured, for example, PostgreSQL not starting because the security context define a different user from the one on the image, or that was defined previously ergo you'll see permissions issue.

I do agree with the statement that misconfigured SecurityContext(SC) is a risk. Still, the lack of opportunity to configure it is a risk also and could be a blocker to adopting it in some environments. For example, in the OpenShift/OKD environments, UID/GID could be randomized, and now you have to do tricks with AdmissionControllers/Kyverno and Cluster manifest simultaneously(just to set SC for the cnpg pods)! Also, at the moment, spec.postgres[UID, GID] is not propagated to the SC level, which is a big problem for me.

Also, you're touching the pgbouncer one, that should be handled using the PodTemplate not using the options from the cluster.

If you look at my change around the pgbouncer, you'll see that I'm not doing anything new (the seccomp profile was consumed from the Cluster spec before my changes).
After a deeper code evaluation, you'll find these two helpers used to create the deployment for pooler/pgbouncer:

• WithSecurityContext
• WithContainerSecurityContext

It's already working as you want it to: if SC is defined in the PodTemplate, it will be utilized; otherwise, it will use the cnpg defaults.

/test

@mnencia, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/19075418581