Open rolandkool opened 3 years ago
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
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?
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.
We're still thinking of looking into this.
@mathieu-benoit all that's missing for this issue to be closed is the two databases, correct?
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
@bourgeoisor I assign it to you for the follow up. Please, update the current status of running ledge-db container as non-root user.
Update to cool down out-of-SLO list:
I have committed the last commit having command /gcbrun
in it, but still it doesn't seems to trigger the build, maybe I don't have the permissions, any thoughts please? @NimJay @bourgeoisor
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.