Custom Security Context in postgresql

[olivejing]

• **Which image of the operator are you using?
  postgres-operator:v1.9.0
• **Where do you run it - cloud or metal?
  Kubernetes and OpenShift
• Type of issue?
  feature request

Hi, i checked postgres operator configuration and postgresql manifest, there is no parameter to custom SecurityContext. Parameter additional_pod_capabilities only supports adding capabilities in container level SecurityContex. Actually, i want to custom pod level and container lever SecurityContext, example:

pod level SecurityContext:

        securityContext:
          fsGroup: 7777
          runAsNonRoot: true
          runAsUser: 7777

container level SecurityContext:

          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
              - ALL
            privileged: false
            readOnlyRootFilesystem: true
            seccompProfile:
              type: RuntimeDefault

[hshmilo]

Postgresql, OperatorConfiguration CRDs provide a rather limited set of SecurityContext configuration properties. I could not find a way how to configure the following properties:

1. seccompProfile for the pod SecurityContext. It supports the spiloRunAsUser, spiloRunAsGroup, spiloFSGroup only.
2. SecurityContext configuration for the sidecar containers is not supported.
3. For the spilo container level is supported only adding capabilities list by the additional_pod_capabilities parameter.

Created the #2244 PR which implements the above features.

[mjdazz]

I hate to be that guy but is there a timeline when (and if) this will be merged? It is a critical thing for the decision for our current setup...

[theobolo]

I agree with @mjdazz that this is a significant issue, as it makes deploying Postgres to Autopilot, for example, impossible.

• Implement generic scheme for avoiding comparison of automatically added/modified properties during update/sync examination #1646
• Experience/problems running Postgres Operator on GKE with Autopilot #1638

[EmilMunksoe]

This MR is very much needed if you are trying to enforce restricted pod policies: https://kubernetes.io/docs/concepts/security/pod-security-standards/ (Yes I know pod policies are deprecated - but you can do the same restricted policy management with Pod Security Admission)

[ajchiarello]

Is there any timeline on when this will be merged, or anything we can do to help it along?

[mattwing]

+1 on needing this to comply with restricted profiles, as @EmilMunksoe mentioned here

There's an open PR here: #2244, just needs a review.

[yyvess]

As Workaround you can use a kyverno ClusterPolicy

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: postgresql-securitycontext
spec:
  rules:
    - name: mutate-postgresql-sts
      match:
        any:
          - resources:
              kinds:
                - Pod
              selector:
                matchLabels:
                  application: spilo
      mutate:
        patchStrategicMerge:
          spec:
            containers:
              - (name): "*"
                securityContext:
                  allowPrivilegeEscalation: false
                  capabilities:
                    drop:
                      - ALL
                  seccompProfile:
                    type: RuntimeDefault
            securityContext:
              runAsNonRoot: true

[zacharyljones]

+1 - Is there anything that I can do to help move this along?

I'm using this operator within vClusters, and can't use the Kyverno Policy workaround until vCluster's next major release (https://www.vcluster.com/docs/platform/integrations/host-kyverno). It seems like my only option would be to wait for that release or switch to the CNPG Operator.