Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Components should not require root to run #517

Open
rolandkool opened this issue Jul 30, 2021 · 9 comments · May be fixed by #2167
Open

Components should not require root to run #517

rolandkool opened this issue Jul 30, 2021 · 9 comments · May be fixed by #2167
Labels
good first issue This issue is a good place to started contributing to this repository. priority: p3 Desirable enhancement or fix. May not be included in next release. samples Issues that are directly related to samples. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.

Comments

@rolandkool
Copy link

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
Copy link
Author

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 bourgeoisor added priority: p3 Desirable enhancement or fix. May not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Aug 4, 2021
@bourgeoisor
Copy link
Member

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
Copy link
Author

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
Copy link
Member

We're still thinking of looking into this.

@mathieu-benoit mathieu-benoit linked a pull request Jun 21, 2022 that will close this issue
4 tasks
@mathieu-benoit mathieu-benoit removed a link to a pull request Jun 21, 2022
4 tasks
@iennae iennae added the samples Issues that are directly related to samples. label Aug 24, 2022
@bourgeoisor
Copy link
Member

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

@mathieu-benoit
Copy link
Contributor

mathieu-benoit commented Oct 21, 2022

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
Copy link

minherz commented Dec 14, 2022

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

@NimJay NimJay added the good first issue This issue is a good place to started contributing to this repository. label Jun 26, 2023
@NimJay
Copy link
Collaborator

NimJay commented Jun 26, 2023

Update to cool down out-of-SLO list:

  • Removing @bourgeoisor as assignee, and labeling this issue a "good first issue" (based on Mathieu's suggestion).
  • Anyone can pick this issue up.
  • There are high priority issues on our team, so I doubt our team will be able to address this any time soon.

@rock-007
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue This issue is a good place to started contributing to this repository. priority: p3 Desirable enhancement or fix. May not be included in next release. samples Issues that are directly related to samples. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
7 participants