consul-template container runs as root - breaks CISO compliance

[goffinf]

Version: hashicorp/consul-template:0.23.0-alpine

Whilst the consul-template process within the container runs as a non-root user the container itself runs as root.

For us (a large financial services company) running containers with the root user is explicitly dis-allowed by our CISO as a mandatory control and enforced both by image and run-time assurance policies (i.e launch of the container is blocked) Running containers as non-root is also widely recognised as a recommended security best practice.

/ # id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
/ # 
/ # whoami
root
/ # 
/ # ps
PID   USER     TIME  COMMAND
    1 root      0:00 {docker-entrypoi} /bin/dumb-init /bin/sh /bin/docker-entrypoint.sh -config=/etc/consul-template/consul-template-config.hcl -log-level=debug
    6 consul-t  0:00 /bin/consul-template -config=/consul-template/config -config=/etc/consul-template/consul-template-config.hcl -log-level=debug
   27 root      0:00 /bin/sh
   37 root      0:00 ps
/ #

We run consul-template containers within Kubernetes which also applies a restricted Pod Security Policy which specifically prevents containers running as root (this is also common practice)

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
  ...
spec:
...
  runAsUser:
    rule: MustRunAsNonRoot

We have asked Hashicorp support to remediate this issue, however, they have stated that consul-template is a community project and changes are only supported by issues raised in this repo.

[eikenb]

Hey @goffinf, thanks for raising this issue.

Just to be sure I understand correctly... it is that the entrypoint script is run as root that is the issue? If that is correct, it seems like setting the USER in the Dockerfile would resolve this issue. Does that sound right to you?

[goffinf]

Hey John,

Thanks for picking this up.

Yes, as you can see from the process output above, consul-template itself runs as the consul-template user (UID=1000) within the container (and uses dumb-init to enable reaping of zombie sub-processes) but the container itself runs as root. The container is launched via the entry point script.

The consul-template user is created within the Dcokerfile and the entrypoint script ensure that user is used via gosu

RUN addgroup consul-template && \
    adduser -S -G consul-template consul-template

I’m pretty sure I tried using a securityContext in the K8s manifest to run the container as UID 1000 but then consul-template itself errors on launch (I’ll do that again today and post the config and it’s output). So it may not be as straightforward as setting the USER directive ?

Regards

Fraser.

[eikenb]

Hey @goffinf, sorry for the delay. Got sidetracked by other priorities for a time.

After playing around with this it looks like the error you get is simply due to the use of gosu. It (gosu) tries to switch users even if it is already that user and it doesn't have permission to do so... but it doesn't need to if you specify the USER in the Dockerfile.

By adding a USER directive and removing the gosu it runs fine.

The one issue about changing everything to run as the consul-template user is that it currently utilizes the root privs to chown the directories in the exported Volume in case the mount point has bad privs. IMO this is a bad practice anyways. I'm going to make the change and list that as a possible breaking change.