fix: use the non-root atlantis user instead of root

[bschaatsbergen]

what

• Make standard use of the atlantis user and not root.
• Removed gosu, as we're using the atlantis user anyways
• Set DOCKER_CONTENT_TRUST=1 anywhere we build

why

• gosu has various security issues reported (see reported issues)
• it's not a good practice to use the root user by default

tests

references

• Closes Run docker container as atlantis instead of root #3777
• Partially fixes Fix dockle container security issues #3789

[bschaatsbergen]

TODO: needs testing locally

[bschaatsbergen]

@nitrocode, @GenPage, @jamengual if you have some time later this week - I consider this quite an impactful change and it would require thorough testing before shipping it.

[nitrocode]

@bschaatsbergen I see the tests pass which is great but it would be nice to test this out in your setup and verify the following

• atlantis project autodiscovery
• atlantis website for locks and plans
• atlantis init/plan/apply workflow
• atlantis downloading terraform binaries
• anything else that uses local storage?

[nitrocode]

One thing I'm curious about is why there do not need to be any chmod or chown changes as part of this pr?

[bschaatsbergen]

One thing I'm curious about is why there do not need to be any chmod or chown changes as part of this pr?

Yes, I think we do - as we've removed the line adduser atlantis root the chmod g=u ... would be useless, as the atlantis user is no longer in the root group. I'll work on this too.

[nitrocode]

Thanks @bschaatsbergen. Please also rerun dockle and show the output in the pr summary. If we can reduce that to zero and still have atlantis running as usual then that would fully close our the associated issue.

[bschaatsbergen]

@bschaatsbergen I see the tests pass which is great but it would be nice to test this out in your setup and verify the following

• atlantis project autodiscovery
• atlantis website for locks and plans
• atlantis init/plan/apply workflow
• atlantis downloading terraform binaries
• anything else that uses local storage?

Tested:

✅ atlantis website for locks and plans
✅ atlantis init/plan/apply workflow
✅ atlantis downloading terraform binaries
✅ cloning of the git repository
✅ being able to mount a persistent data disk and use that as atlantis' home directory
✅ writing to local storage using Terraform

[bschaatsbergen]

dockle seems to be happy overall, note solving CIS-DI-0008 is quite hard and as it's an info level check I think that we can skip it and address it in the nearby future if it ever posses a problem?

$ dockle ghcr.io/bschaatsbergen/atlantis:dev-alpine-2d7ba9e
$ dockle ghcr.io/bschaatsbergen/atlantis:dev-debian-2d7ba9e
INFO - CIS-DI-0008: Confirm safety of setuid/setgid files

• setuid file: urwxr-xr-x usr/bin/mount
• setuid file: urwxr-xr-x usr/lib/openssh/ssh-keysign
• setuid file: urwxr-xr-x usr/bin/newgrp
• setuid file: urwxr-xr-x usr/bin/chfn
• setgid file: grwxr-xr-x usr/bin/ssh-agent
• setgid file: grwxr-xr-x usr/sbin/unix_chkpwd
• setuid file: urwxr-xr-x usr/bin/passwd
• setuid file: urwxr-xr-x usr/bin/gpasswd
• setuid file: urwxr-xr-x usr/bin/su
• setuid file: urwxr-xr-x usr/bin/umount
• setgid file: grwxr-xr-x usr/bin/wall
• setgid file: grwxr-xr-x usr/bin/expiry
• setgid file: grwxr-xr-x usr/bin/chage
• setuid file: urwxr-xr-x usr/bin/chsh

[bschaatsbergen]

This is ready for review @nitrocode, @jamengual, @GenPage - I've extensively tested the alpine image (besides autodiscovery) and I'm unable to test out the debian image - if one of you could check the debian image out that would be appreciated.

I've published both an alpine as well as a debian image:

• ghcr.io/bschaatsbergen/atlantis:dev-alpine-2d7ba9e
• ghcr.io/bschaatsbergen/atlantis:dev-debian-2d7ba9e

[nitrocode]

How come the chmod of /etc/passwd needs to change? If the line is removed, can atlantis still function?

[bschaatsbergen]

the previous chmod g=u sets the group permissions for the /home/atlantis/ directory to be the same as the user's permissions.

The new chmod sets the user's permissions for the /home/atlantis/ directory to read, write (and execute).

So, the change here is that the original command was changing group permissions to match user permissions, and it has been modified to give the user explicit permissions instead.

[nitrocode]

Right but I don't understand why /etc/passwd perms need to be changed. Can we get away with only changing /home/atlantis ?

[bschaatsbergen]

Ah, I didn't want to break anything. Therefor I just gave it read write permissions. We can't use g=u anymore though.

[nitrocode]

Ok no worries then, can always tackle it later. Thank you!

[nitrocode]

Ok but the more changes made, the more likely something can break. I'm all for more security, provided @bschaatsbergen has the appetite to keep going 🙏

[bschaatsbergen]

Is this really the case? I'm happy to add it, but couldn't find it anywhere. I know that users start from 1000 though. Is there a particular reason we should explicitly set this? Omitting it would prevent a uid and gid conflict right? @jamengual

[bschaatsbergen]

I've set uid/gid 100:1000 and removed the passwd entry lines.

[arohter]

alpine and debian have different uid's it appears: #3317 (comment)
alpine: uid=100, debian: uid=1000

[bschaatsbergen]

@arohter it's removed again, to stay inline with what's in the Dockerfile now. to avoid touching the uid and gid at all.

[GenPage]

Approved, all of my concerns were already addressed. Is there anything left to do @bschaatsbergen based on your last comment?

[bschaatsbergen]

Approved, all of my concerns were already addressed. Is there anything left to do @bschaatsbergen based on your last comment?

there is one more comment to resolve, which is about the passwd file changes.

Fixing this today, been a hectic week!

[jamengual]

/cherry-pick release-0.26

[Alex-Mussell]

Asked to comment: https://atlantis-community.slack.com/archives/C5MGGAV0C/p1702475459555389 here as there probably needs to be some documentation in the release notes regarding this update. But here is the lowdown.

We use the Atlantis image as a base image and added some extra functionality to the container like so:

BEFORE:

FROM ghcr.io/runatlantis/atlantis:v0.27.0-alpine
RUN apk add --no-cache python3 python3-dev py3-pip libc-dev libffi-dev gcc jq yq
RUN pip3 install --upgrade pip
RUN pip3 install --no-cache-dir \
  'msal==1.4.3' \
  'awscli'

etc.etc.

And this worked fine prior to v0.27.0. However we started to get an error: #8 0.951 ERROR: Unable to lock database: Permission denied , having looked around I resolved this by then doing the following (notice how I also had to create a virtualenv to be able to upgrade pip once the above error was resolved):

AFTER:

FROM ghcr.io/runatlantis/atlantis:v0.27.0-alpine
USER root   <------ ADDED

ENV VIRTUAL_ENV=/opt/venv
RUN apk add --no-cache python3 python3-dev py3-pip libc-dev libffi-dev gcc jq yq
RUN python3 -m venv $VIRTUAL_ENV
## We can replace source <venv>/activate by setting the appropriate environment variables: Docker's ENV command applies both subsequent RUNs as well as to the CMD.
ENV PATH="$VIRTUAL_ENV/bin:$PATH"
RUN pip3 install --upgrade pip
RUN pip3 install --no-cache-dir \
  'msal==1.4.3' \
  'awscli'

etc.etc.

USER atlantis   <----- ADDED

Next we deploy this container via Ansible onto an EC2 instance, but there needed to be some changes in some tasks as we are now the atlantis user. Any time a task that requires you to be root within the container on the host, you now need to explicitly define the root user as the executor of the task. For example, we have an AWS config that needs to be readable by the atlantis user.

BEFORE:
- name: Make AWS conf readable by Atlantis
  community.docker.docker_container_exec:
    container: atlantis
    command: /bin/bash -c "chown atlantis:atlantis /home/atlantis/.aws/"

AFTER:
- name: Make AWS conf readable by Atlantis
  community.docker.docker_container_exec:
    user: root
    container: atlantis
    command: /bin/bash -c "chown atlantis:atlantis /home/atlantis/.aws/"