Components should not require root to run

[rolandkool]

In clusters with PodSecurityPolicies active and restrictions on which images can run as root, it's hard to deploy this demo application. The DB components fail to start when trying to start as non root (using the postgres user (id 70) in the securityContext).
The app components requiring the JWT secret also fail to start as the key is mounted and expected in the /root directory.

[rolandkool]

For the application parts, the path for the JWT key is configurable so I can get those to run as nonroot by using /tmp instead of /root

[bourgeoisor]

Thank you for filing this issue, Roland! This is definitely an unintended results of using root in some of our images. Could you provide us with some more details of which images are blocked because of this root-user issue and how this could be mitigated?

[rolandkool]

I've managed to get all working without root, except for the two database ones.
For the application ones, the issue is with the pubkey that is (by default) stored in the /root directory. Luckily, the path can be adjusted through the configmap and by tweaking the deployment spec.

For the two postgres images, I've tried setting the user to 70, which is the id of the postgres user available in the image. Unfortunately, this does not make it start up, but not sure why.

[bourgeoisor]

We're still thinking of looking into this.

[bourgeoisor]

@mathieu-benoit all that's missing for this issue to be closed is the two databases, correct?

[mathieu-benoit]

ledger-db and accounts-db are the only ones which still run as root.

It would be great if someone could look at this. When doing this:

kind: StatefulSet
apiVersion: apps/v1
metadata:
  name: ledger-db
spec:
  serviceName: "ledger-db"
  replicas: 1
  selector:
    matchLabels:
      app: ledger-db
  template:
    metadata:
      labels:
        app: ledger-db
    spec:
      serviceAccountName: default
      securityContext:
        fsGroup: 1000
        runAsGroup: 1000
        runAsNonRoot: true
        runAsUser: 1000
      containers:
        - name: postgres
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - all
            privileged: false
            readOnlyRootFilesystem: true
          image: gcr.io/bank-of-anthos-ci/ledger-db:v0.5.8
          ports:
            - containerPort: 5432
          envFrom:
            - configMapRef:
                name: environment-config
            - configMapRef:
                name: ledger-db-config
            - configMapRef:
                name: demo-data-config
          resources:
            requests:
              cpu: 100m
              memory: 512Mi
            limits:
              cpu: 250m
              memory: 1Gi
          volumeMounts:
            - name: postgresdb
              mountPath: /var/lib/postgresql/data
              subPath: postgres
      volumes:
        - name: postgresdb
          emptyDir: {}

We got this errors in the logs of the associated Pod:

chmod: changing permissions of '/var/lib/postgresql/data': Operation not permitted
chmod: changing permissions of '/var/run/postgresql': Read-only file system
initdb: could not look up effective user ID 1000: user does not exist

This issue is in the Dockerfile files and how this container is built to run .sql and .sh files: chmod 755, etc.

Good first issue anyone? :)

This will remove 2 Configurations concerns per container from the GKE Security Posture:

Configuration | Pod container allows privilege escalation on exec
Configuration | Pod container is allowed to run as root

[minherz]

@bourgeoisor I assign it to you for the follow up. Please, update the current status of running ledge-db container as non-root user.