docker-ansible icon indicating copy to clipboard operation
docker-ansible copied to clipboard

Adds gitlab-runner user and group

Open madeinoz67 opened this issue 6 years ago • 3 comments

This merge request adds a gitlab-runner user and group and then defaults to this user

Reason:

  1. To be more consistent with existing gitlab runners which get executed as the gitlab-runner user by default.

  2. allows existing playbooks to connect to hosts that refuse root connections via ssh

madeinoz67 avatar Dec 13 '18 08:12 madeinoz67

added a working example with names changed to protect the innocent

madeinoz67 avatar Dec 13 '18 08:12 madeinoz67

Hey thanks for the PR, I really consider merging this. I'd like to get a bit more details concerning the user.

  1. To be more consistent with existing gitlab runners which get executed as the gitlab-runner user by default.
  • Is it better to use a different user than root in a Dockerfile?
  • Is this about security?

I found the following article here which states the following:

Processes in a container should not run as root, or assume that they are root. Instead, create a user in your Dockerfile with a known UID and GID, and run your process as this user. Images that follow this pattern are easier to run securely by limiting access to resources.

So I guess this is the right thing to do. Any reason why naming it gitlab-runner other than the fact the examples are for gitlab? Because in a way, this image is not gitlab dependent and I'm wondering if this would make people think it only works with gitlab (because it clearly should work with anything else).

  1. allows existing playbooks to connect to hosts that refuse root connections via ssh

Can you explain this a little more? I did not work a lot with ansible yet, I only have quite simple playbooks on my side and I don't think I've hit this limitation. Is it that some ansible commands can execute on a remote server and then try to execute things on the host (the runner) but it fails when it's root? Do you have any source for this?

Thanks for the full example, I'll add a link in the readme to this as a "see a complete example here". btw, image is updated to latest version so you can bump to 2.7.5 ;)

GabLeRoux avatar Dec 20 '18 15:12 GabLeRoux

hi @GabLeRoux

sorry for the delay in replying,

  1. To be more consistent with existing gitlab runners which get executed as the gitlab-runner user by default.
  • Is it better to use a different user than root in a Dockerfile?
  • Is this about security?

in short yes

So I guess this is the right thing to do. Any reason why naming it gitlab-runner other than the fact the examples are for gitlab? Because in a way, this image is not gitlab dependent and I'm wondering if this would make people think it only works with gitlab (because it clearly should work with anything else).

reason I've used gitlab-runner user is this is the default user that the gitlab-runner services get installed under on runner machines. I was assuming that you were targeting gitlab for this image as your docs etc seem to indicate, also my search around gitlab-ci, docker and ansible lead me to this project :)

I run an internal gitlab server with internal gitlab-runners for my pipelines on my network. What I do is provision this proxy user on any machine that will be the target of a CI/CD pipeline, then my ansible playbooks do the rest once I check them in, previously I used the runner shell script to execute my playbooks, now is done via this docker image, as is much easier to keep everything up to date in a docker image.

It could be any user you deem to be the CI proxy user. I've kept it simple for gitlab integration.

  1. allows existing playbooks to connect to hosts that refuse root connections via ssh

Can you explain this a little more? I did not work a lot with ansible yet, I only have quite simple playbooks on my side and I don't think I've hit this limitation. Is it that some ansible commands can execute on a remote server and then try to execute things on the host (the runner) but it fails when it's root? Do you have any source for this?

Again this is about security. Its good practice not to allow ssh for root from network so you need to log in as a normal user via ssh then sudo etc. It also gives a bit of an audit trail in terms of what was done and by whom.

Thanks for the full example, I'll add a link in the readme to this as a "see a complete example here". btw, image is updated to latest version so you can bump to 2.7.5 ;)

Cheers. It took me a bit of working out with just your README as reference so once I figured it out that example is the result in my working solution using your image.

I'll also be submitting another PR once I get back to work after the new year for working with Windows Active Directory host targets with this image and will include an example as well. I have it working well, just need to look at a way of allowing customising the Kerberos config without rebuilding the image so is more generic.

madeinoz67 avatar Dec 30 '18 01:12 madeinoz67