Custom SecurityContext in Postgresql, OperatorConfiguration CRDs

[hshmilo]

This PR extends the Postgresql, OperatorConfiguration CRDs with the following list of properties related to pod/containers SecurityContext. Postgresql CRD:

1. spiloSeccompProfile – adds SeccompProfile config property on the cluster pod level.
2. securityContext for the sidecars configuration – configures securityContext property for particular sidecar container.

OperatorConfiguration CRD:

1. dropped_pod_capabilities - list of dropped capabilities for spilo container.
2. spilo_seccompprofile – adds SeccompProfile config property on clusters pod level.
3. securityContext for the sidecars configuration – configures securityContext property for particular sidecar container.

This PR addresses #2223

[EmilMunksoe]

+1

[x3rus]

+1

[ugur99]

Hi everyone, any updates regarding this PR?

[m1m1x]

Hi,

any chance to review this MR please? It would be a good addition for cluster security in depth.

[mattwing]

+1 on needing this to comply with restricted profiles, as @EmilMunksoe mentioned https://github.com/zalando/postgres-operator/issues/2223#issuecomment-1527082580

[Tahedah]

Hey, this is also a blocker for us since we have strict pod policies for the clusters. Is this something that will be merged soon?

[sj-porter-knime]

+1

[BalintCsonka]

+1

[mrpainte]

+1 this would allow my team to be able to deploy postgres into our clusters with this operator

[bumarcell]

Why is this MR (which will make many lives easier) ignored for over a year now? waiting only makes it more complicated to merge and now there are merge conflicts to resolve. I hope there's a good reason for that.. 😓

[ajchiarello]

Honestly, the delay on this led me to move from this operator over the CloudNative PostgreSQL Operator, which does everything and is already secure.

[sdesbure]

Honestly, the delay on this led me to move from this operator over the CloudNative PostgreSQL Operator, which does everything and is already secure.

same here :(

[zacharyljones]

+1

[mheers]

I circumvented the problem with a MutatingWebhookConfiguration and the corresponding controller:

https://github.com/mheers/pod-spec-mutator

You create a deployment with an env var that specifies how the pod will modified before starting: https://github.com/mheers/pod-spec-mutator/blob/main/deploy/deployment.yaml#L38

With this one can easily specify the SecurityContext and have it merged in the starting pods specification on-the-fly.

[ajchiarello]

I circumvented the problem with a MutatingWebhookConfiguration and the corresponding controller:

I circumvented the problem by moving to the CNPG Operator which does everything securely by default.

[mheers]

I circumvented the problem with a MutatingWebhookConfiguration and the corresponding controller:

I circumvented the problem by moving to the CNPG Operator which does everything securely by default.

I also checked CNPG and indeed it offers to set the SecurityContext, but I also need to define additional volumes and hostAliases - which is also not supported by CNPG so I sticked with zalando and built the admission-hook.

[chef-6229]

please merge this PR

[sj-porter-knime]

I think labeling this PR as minor might be a bit of an understatement - setting restricted security contexts is a best practice for any database running in Kubernetes and increasingly becoming a hard requirement. Almost every company we see using Kubernetes is installing tools like Kyverno or Gatekeeper to enforce security policies, making Postgres instances controlled via this operator a security exception in every single case. Using mutation policies with Kyverno is a creative workaround for those brave enough to use mutation policies, but also a bit of an anti-pattern.

Could we please get an acknowledgement or response from the PR reviewers (or other repo maintainers) with current status and/or some steps that community members can take to help it along? Do you need testers, or is there something else you're concerned about that we can help with? Migrating to another Postgres Operator would be a large undertaking for us, but if we can't get these security exceptions resolved, we may be forced to migrate at some point like others already have.

[szuecs]

I am not part of postgres-operator maintainers, but from kubernetes point of view I have some idea. I hope my questions are fine and help to get some things sorted out.