Search code examples
bashazure-devops

How run a azure container job under a specific user in the container


running a container-job in an azure pipeline, I use a docker image ( conan ) which expects the build commands to be run under conan.

While I'm able to bootstrap the container in azure with --user root without issues using options

resources:
  containers:
  - container: builder                  
    image: conanio/clang8
    options: --user root

When I run a job

jobs:
- job: do_that
  container: builder
  steps:
  - task: Bash@3
    inputs:
      targetType: inline
      script: whoami
      noProfile: false
      noRc: false

I see that the user is 1001 which has been craeted by the azure bootstrap. I cannot use sudo / su since the user is not allowed to use sudo. I ask myself how would I ever run as a different user? The user has a specific ENV setup due to python shims for conan, special setups in ~/.conan, and all those kind of things.

This exact steps in azp runs automatically during the "container initialization" (right after docker create) in az using docker exec are:

# Grant user 'conan' SUDO privilege and allow it run any command without authentication.
groupadd azure_pipelines_sudo
usermod -a -G azure_pipelines_sudo conan
su -c "echo '%azure_pipelines_sudo ALL=(ALL:ALL) NOPASSWD:ALL' >> /etc/sudoers"

# Allow user 'conan' run any docker command without SUDO.
stat -c %g /var/run/docker.sock
bash -c "cat /etc/group"
groupadd -g 117 azure_pipelines_docker
usermod -a -G azure_pipelines_docker conan

The semantic idea is:

  1. extract which user the image is designed to run on by default ( in our case conan / 1000
  2. create a group azure_pipelines_sudo
  3. grant this user sudo permissions without password requirements
  4. grant this user conan permissions to access the docker socket aka run docker in docker commands

Seeing this setup I really wonder, why effectively then the docker exec statement is run using something along the lines as

docker exec -u 1001 ..

So effectively when the actual job is run, it is not using the user conan (1000) - so the one being configured to have all the capabilities like sudo / docker access - if that is by design, why doing the setup 2-4 at all?

Somewhat this looks like either a design flaw, a bug, or just a huge misunderstanding on my side.

I have seen this question but even though the title assumes, it is a very different question


Solution

  • Right now, this is not possible. I'am not sure what this whole concept is about, but for me that is not only an issue, it is an showstopper because one cannot workaround this issue.

    Even though it is a simple answer - at least it is one.