Support run_as_group

[henrysachs]

Hey There,

to get right into the specifics. I'm currently trying to build an apko image for the gitlab runner helper. More specifically I'm trying to rebuild the ubi image version (see https://gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images/container_registry/1766433) of it because my kubernetes Environment restricts to run as root (but i dont run in openshift).

When inspecting the original image i see that it runs as user 1001 and group 0

When trying to set these in my apko yaml i wont receive the right group in the end (probably because beeing part of the root group is not good) So do you have any ideas what I could do against this or how i could run as group 0?

this is my current apko yaml

contents:
  packages:
    - busybox
    - bash
    - ca-certificates
    - dumb-init
    - git
    - git-lfs
    - curl
    - zlib 
    - pcre2 
    - gitlab-runner-helper=17.4.0
    - gitlab-runner-helper-oci-entrypoint=17.4.0
    - gitlab-runner-helper-compat=17.4.0

accounts:
  groups:
    - groupname: gitlab-runner
      gid: 65533
  users:
    - username: gitlab-runner-helper
      uid: 1001
      gid: 0
      shell: /bin/sh
  run-as: gitlab-runner-helper

paths:
  - path: /home
    type: directory
    uid: 1001
    gid: 65533
    permissions: 0o755
  - path: /home/gitlab-runner
    type: directory
    uid: 1001
    gid: 65533
    permissions: 0o755
  - path: /home/gitlab-runner/.gitlab-runner
    type: directory
    uid: 1001
    gid: 65533
    permissions: 0o755
  - path: /cache
    type: directory
    uid: 1001
    gid: 65533
    permissions: 0o777

entrypoint:
  command: "/usr/bin/dumb-init /entrypoint"

cmd: "sh"

thanks in advance!

[amouat]

Just to be clear, you're saying if you set gid to 0 it doesn't work?

[henrysachs]

yes if i run it with gid: 0

I receive the following in my build container:

❯ docker run -it latest:latest-amd64
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
/ $ id
uid=1001(gitlab-runner-helper) gid=1001 groups=1001

PS: I editted my yaml from above to reflect the gid field better

[henrysachs]

I just saw that you guys are also building a gitlab-runner-helper and when taking a peak at the specifications it seems like you're using a non root user for it: https://images.chainguard.dev/directory/image/gitlab-runner-helper/specifications but when using this in gitlab ci and doing file operations like chmod I think there would be issues. Maybe you allow a peak behind the glass how you achieved this? 🥺 😅

[xnox]

I just saw that you guys are also building a gitlab-runner-helper and when taking a peak at the specifications it seems like you're using a non root user for it: https://images.chainguard.dev/directory/image/gitlab-runner-helper/specifications but when using this in gitlab ci and doing file operations like chmod I think there would be issues. Maybe you allow a peak behind the glass how you achieved this? 🥺 😅

Does https://images.chainguard.dev/directory/image/gitlab-runner-helper/overview help at all? Or contact your Chainguard Images support via zendesk.

[henrysachs]

I think there was a misunderstanding. I'm not a premium customer sorry about that. I just saw that you already offer images for the use case that i'm building. But you're using different users than I'm and I wasn't quite sure how yours works in gitlab-ci environments as i think there would be issues in pipelines that rely on certain file permissions.

[xnox]

I think there was a misunderstanding. I'm not a premium customer sorry about that. I just saw that you already offer images for the use case that i'm building. But you're using different users than I'm and I wasn't quite sure how yours works in gitlab-ci environments as i think there would be issues in pipelines that rely on certain file permissions.

I believe gitlab charts allow both methods to run as root; and as nonroot. There are many helm deployments that allow one to change settings ".runAsNonRoot" as true or false. Afterall what container defaults to run-as is only a suggestion; and in your helm chart you can always update it to set a given container to run priviledged and as a real root. If you so desire in your deployment.

We always try to create non-root user in chainguard containers, because it is very difficult to run as non-root; if container doesn't have a non-root user; non-root permissions; etc. Opting into running as root is trivial, the opt-out is not.

[henrysachs]

yes youre totally right about this! But I think in the case of the gitlab runner and gitlab-runner-helper this is a bit more complex. Because all files owned downloaded by the gitlab-runner-helper get the permissions of the user and his groups of the user running in the helper container. This is why i think gitlab is using 1000:0 as his user in openshift environments as its quite "generic" and not prone to escalations. I thought maybe you can give some insights into how you're using those images