Not able to set the container securityContext

[andreasgeisslerdt]

Overview

I would like to update the container securityContext of the pgBouncer.
According to the CRD (https://access.crunchydata.com/documentation/postgres-operator/latest/references/crd/5.5.x/postgrescluster#postgresclusterspecproxypgbouncercontainersindex) I set it like:

---
apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
...
spec:
  proxy:
    pgBouncer:
    ...
      containers:
        - name: pgbouncer
          securityContext:
            capabilities:
              drop:
                - ALL
                - CAP_NET_RAW
        - name: pgbouncer-config
          securityContext:
            capabilities:
              drop:
                - ALL
                - CAP_NET_RAW

but the pgbouncer pods are not changed.

Environment

Please provide the following details:

• Platform: (Kubernetes)
• Platform Version: (1.29.1)
• PGO Image Tag: (ubi8-5.5.0-0)
• Postgres Version (16)
• Storage: (e.g. hostpath, nfs, or the name of your storage class)

Steps to Reproduce

REPRO

Provide steps to get to the error condition:

1. Set the container settings above
2. Check pgbouncer pod

EXPECTED

1. SecurityPolicies are updated

ACTUAL

1. SecurityContext is not changed

...
  containers:
    - name: pgbouncer
      ...
      securityContext:
        capabilities:
          drop:
            - ALL
        privileged: false
        runAsNonRoot: true
        readOnlyRootFilesystem: true
        allowPrivilegeEscalation: false

[tjmoore4]

Hi @andreasgeisslerdt. The setting in question, spec.proxy.pgBouncer.containers, would be used by a custom sidecar container, not the existing pgBouncer containers (please see this section of our documentation for more information). With that said, the security context values are currently hard coded as shown, but I have added an issue to our backlog for consideration.

[andrewlecuyer]

Hi @andreasgeisslerdt! Can you provide some additional clarification around your specific use-case? More specifically, I am trying to better understand the behavior you are looking for by explicitly providing the securityContext per the spec you provided above.

I am curious, because if you look at CPK's default securityContext configuration for both the pgbouncer and pgbouncer-config containers, you can see that ALL capabilities are already being dropped:

$ kubectl get pod hippo-pgbouncer-566584db88-jbzzj -n postgres-operator -o yaml
...
    name: pgbouncer
    ports:
    - containerPort: 5432
      name: pgbouncer
      protocol: TCP
    resources: {}
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
 ...
    name: pgbouncer-config
    resources: {}
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
...

As a result, it shouldn't be necessary to explicitly drop any additional capabilities (e.g. CAP_NET_RAW) from the container. So if your goal is to simply ensure all capabilities are dropped from these containers, the default configuration should already have you covered.

[brainstorm82]

Hi @andrewlecuyer the issue is that it is in some environment required to define much stricter rules within the security Context setting. In that case it is necessary to be able to adjust default settings.

In case of drop CAP_NET_RAW.
Yes its true if you drop ALL you also drop CAP_NET_RAW, but you would be able to add it. Some environment therefor explicitly what you to drop CAP_NET_RAW, because in that case you cannot add it anymore.

[andreasgeisslerdt]

The Background is, that we need to fulfill certain security requirements to deploy our software to production.
This is proven by kyverno policy checks and in this case this one is active (https://kyverno.io/policies/best-practices/require-drop-cap-net-raw/require-drop-cap-net-raw/) additioally to that one (https://kyverno.io/policies/best-practices/require-drop-all/require-drop-all/)