8

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

Eugen Mayer
  • 8,942
  • 4
  • 33
  • 57

2 Answers2

8

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.

Eugen Mayer
  • 8,942
  • 4
  • 33
  • 57
-1

Update:

This is not available at present.

For your concern:

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?

There is some related info in our official doc may related to this: since Azure Pipelines will docker create an awaiting container and docker exec a series of commands which expect the container is always up and running. https://learn.microsoft.com/en-us/azure/devops/pipelines/process/container-phases?view=azure-devops&tabs=yaml#linux-based-containers

There are three different authentication tokens used by an agent:

  • Agent registration token: used only when registering the agent in the agent pool
  • Listener OAuth token: used by the agent when listening for new jobs
  • Job-specific OAuth token: used by the agent when running an individual job

Even though that link question is not related to yours. But there is a comment is correct:

The agent itself is setup to run as a user. When the build runs it runs in a container as user "containeradministrator"(root) which is a docker user.

What you would like seems to be running a Docker container as a non-root user. This is actually not related to Azure DevOps Service side, more related to Docker.

Kindly check if this helps Connect to docker container as user other than root & this blog.

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • We'll i'am not sure where I have a misunderstanding right now but let's split what the image has been build to run as and what the docker exec command az runs runs at, all beside what the docker-engine host runs as. The exec command is run using 1001, obv. not root but far more important, not sudo-able by design. The 1001 user is created after container RUN by az, then the jobs are started. Where an what does this correlate to the agent user or the other post? – Eugen Mayer Dec 31 '19 at 15:24
  • To be frank, i'am very familiar with docker and all the things you linked, but in the CI env for az I let az handle the container and the exec tunnel, thus I have not access to the EXEC args at all – Eugen Mayer Dec 31 '19 at 15:26
  • Hi @EugenMayer Sorry for misunderstanding. I was supposed to answer your original title `Run a azure job as a specific user`. For updated title How run a azure container job under a specific user in the container. It's not available. For your concern in update. There is some related info in our official doc: since Azure Pipelines will docker create an awaiting container and docker exec a series of commands which expect the container is always up and running. https://docs.microsoft.com/en-us/azure/devops/pipelines/process/container-phases?view=azure-devops&tabs=yaml#linux-based-containers – PatrickLu-MSFT Jan 02 '20 at 15:27
  • 1
    Thank you, yes I changed the title remove the ambiguity. The second section of my question already reflects that i'am aware of that process of the setup/create. What I ask myself.. why. Why would one grant sudo permissions for the image default user, here 1000, and then enforce user 1001 in exec, while 1001 has no sudo permissions and cannot change to 1000 ever. In the az pipeline the 1000 is entirely useless, but you upgrade the user with sudo. It seems entirely without use, while there should be a use actually and it's needed, by far not optional. Giving 1001 sudo permissions would solve thi – Eugen Mayer Jan 02 '20 at 17:30