runatlantis / helm-charts

Atlantis Helm Chart
Apache License 2.0
109 stars 174 forks source link

Security Context runAsUser doesn't match atlantis user in Debian image #306

Open gtirloni opened 1 year ago

gtirloni commented 1 year ago

While deploying Atlantis, I noticed it failed to start whenever I enabled --write-git-creds:

Error: initializing server: writing generated .git-credentials file with user, token and hostname to /nonexistent/.git-credentials: open /nonexistent/.git-credentials: no such file or directory

Upon removing that option, I noticed that Atlantis was running as the _apt user in the Debian image:

_apt@atlantis-0:/$ ps auxw
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
_apt         1  0.0  0.0   2228   504 ?        Ss   14:28   0:00 /usr/bin/dumb-init /bin/sh /usr/local/bin/docker-entrypoint.sh server
_apt         7  0.1  0.3 737820 24748 ?        Ssl  14:28   0:00 atlantis server
_apt        31  0.0  0.0   4156  3464 pts/0    Ss   14:28   0:00 /bin/bash
_apt        37  0.0  0.0   6752  3024 pts/0    R+   14:28   0:00 ps auxw

The chart has runAsUser: 100, which works with the Alpine image because the atlantis user there has uid=100:

044f7697a0f2:/# cat /etc/alpine-release 
3.18.0

044f7697a0f2:/# grep atlantis /etc/passwd
atlantis:x:100:1000:Linux User,,,:/home/atlantis:/sbin/nologin

But not in the Debian image:

93716bd16c43:/# cat /etc/debian_version 
11.7

93716bd16c43:/# grep atlantis /etc/passwd
atlantis:x:1000:1000::/home/atlantis:/bin/bash

The workaround is to set this in values.yaml:

  statefulSet:
    securityContext:
      runAsUser: 1000
jseiser commented 1 year ago

Doesnt this chart default to alpine?

gtirloni commented 1 year ago

Doesnt this chart default to alpine?

That's a good point but the project offers Debian images. Would some documentation change be enough in this case?

GMartinez-Sisti commented 1 year ago

This is because the alpine user is added as a system user (note the -S):

https://github.com/runatlantis/atlantis/blob/dd32a792b7200832853ae331c805a67a850a67a4/Dockerfile#L154

while the debian user is added as a regular user (missing --system):

https://github.com/runatlantis/atlantis/blob/dd32a792b7200832853ae331c805a67a850a67a4/Dockerfile#L193

This needs to be fixed on the Dockerfile and tested to ensure that users currently using the debian image won't have permission issues after upgrading.

arohter commented 1 month ago

I'm running the Debian image, and use only the following:

securityContext:
    fsGroup: 1000

I am not setting runAsUser at all, which should now work just fine for Alpine as well. (afaik we don't need any of the k8s magical permission fixups)

ferpizza commented 1 week ago

Just stumble upon this myself. It's true that users on alpine and debian containers don't share the same uid, and this is troublesome.

Not only because it breaks when you use debian, but also if you switch from alpine to debian (like in our case), all atlantis-data is owned by uid 100 and the debian user cannot access it.

I suggest we use the same uid on both images, to avoid issues such as this. As uid 100 is already used on Debian by sshd, it doesn't seem possible to continue using that one going forward.

Using uid 1000 would work on both alpine and debian.

Not sure why on alpine the Dockerfile is creating a system user on alpine, and a regular user on debian, TBH.

This should be fixed initially on the Dockerfile, here https://github.com/runatlantis/atlantis/blob/main/Dockerfile#L143

And once this is sorted out, then the Helm Chart should be updated.

I can gladly prepare PRs if some existing maintainer agrees with this approach.

GMartinez-Sisti commented 1 week ago

Hi @ferpizza, thanks for the offer but we already have https://github.com/runatlantis/atlantis/pull/4304 waiting to be merged.