/etc/hosts file incorrectly populated when using containerd

[bartlett-ops]

Summary

When using the guardian container runtime, the /etc/hosts file for containers is populated with something like:

127.0.0.1 localhost
10.80.0.2 85feea3d-8ddc-43b7-416a-73409cd3f38c

When using the containerd container runtime, the /etc/hosts file for container is populated with:

127.0.0.1 localhost

This is causes any application that relies on the container hostname for DNS lookups to fail. For my organisation specifically this causes problems for Hadoop.

There is a workaround where the container is run as privileged, and a bootstrap script updates the /etc/hosts file before starting the application.

Steps to reproduce

Hijack a container, or run the following in a task:

cat /etc/hosts

Compare the results when running on guardian and containerd.

Expected results

127.0.0.1 localhost
10.80.0.2 85feea3d-8ddc-43b7-416a-73409cd3f38c

Actual results

127.0.0.1 localhost

Triaging info

• Concourse version: v7.2.0

• Helm Chart: 15.0.3

• Kubernetes (AWS EKS): v1.19.8

• Did this used to work?
  This works when using the guardian container runtime. Containerd as a runtime has only just been introduced

[aoldershaw]

Fixed by #7041 (hasn't yet been released)