[Question]: Why is the default to mount docker.sock socket into containers?

[pixdrift]

Describe your question

This issue is similar to the other discussions regarding the default configuration/behaviour of the ADO agent, and in some ways similar to the request raised by @joshchngs in the following ticket:
#4332

Looking at the code that configures the mount of the docker socket into the pipeline container, it's not clear why it has been added. The comment suggests that docker.sock is enabled default on Linux and not Windows, but it doesn't explain the motivation for mounting it.

azure-pipelines-agent/src/Agent.Sdk/ContainerInfo.cs

Lines 56 to 57 in d8e2b00

	// Windows has never automatically enabled Docker.Sock, but Linux does. So we need to set the default here based on OS.
	this.MapDockerSocket = container.Properties.Get<bool>("mapDockerSocket", !PlatformUtil.RunningOnWindows);

This commit was roughly four years ago, so I suspect this was done as a method to run docker in docker, or execute container builds inside the container agent.

This flag is then used to mount the socket

azure-pipelines-agent/src/Microsoft.VisualStudio.Services.Agent/HostContext.cs

Lines 521 to 524 in d8e2b00

	if (containerInfo.IsJobContainer && containerInfo.MapDockerSocket)
	{
	containerInfo.MountVolumes.Add(new MountVolume("/var/run/docker.sock", "/var/run/docker.sock"));
	}

I don't believe this approach is endorsed anymore, and at worst, this may actually be a security issue depending on how the container host is configured as this socket can provide significant levels of access to host from inside the container. Additionally, modern container implementations such as podman don't use the docker.socket by default, and it would be nice to not have to work around this configuration if it's not required.

I have done some initial investigation on removing this mount, and as it can't be removed from the configuration, one workaround is to create an empty docker.sock file by simply running touch /var/run.docker.sock. This removes the need for the socket all together (and potential security issue), and a dummy file also passes the 'stat' check in the initialisation step here:

azure-pipelines-agent/src/Agent.Worker/ContainerOperationProvider.cs

Line 698 in d8e2b00

string dockerSockGroupId = (await ExecuteCommandAsync(executionContext, "stat", $"{statFormatOption} /var/run/docker.sock")).FirstOrDefault();

When using a dummy file for the docker.sock there has been no impact to container execution, demonstrating that it is not required for common use cases.

This issue is to raise awareness of this default configuration, and request that it be revisited. Ideally I believe the ADO agent configuration should have an option to disable this mount, and potentially also remove it from the default configuration due to security issues (ie. mark as deprecated, and people who explicitly need access to the socket from within the container can turn it on through configuration).

All that being said, interested if anyone is actually using this docker.sock in their Linux containers?

Versions

Azure DevOps Agent 3.220.2

Environment type (Please select at least one environment where you face this issue)

• Self-Hosted
• Microsoft Hosted
• VMSS Pool
• Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Operation system

RHEL 8, RHEL 9

Version controll system

git

Azure DevOps Server Version (if applicable)

Azure DevOps Services

[KonstantinTyukalov]

Hi @pixdrift thank you for the feedback. We have higher priority issues now, but we'll get to that soon.

[github-actions]

This issue has had no activity in 180 days. Please comment if it is not actually stale