Docker Driver: clarify execution daemon access

[simonferquel]

Today Duffle's Docker Driver always mount /var/run/docker.sock in the invocation image. This provides a very easy way to do CNAB composition (CNABs invoking other CNABs) at the cost of exposing the whole engine API to the invocation image, without explicit consent (and of not being able to run Windows based invocation images).

In the case of Docker Enterprise, it is not even possible to do so for most users (for security reasons, mounting host files in a container in Docker EE requires very high privileges).
Also, in the Docker Enterprise case, RBAC rules are entirely bypassed when you manage to mount the docker socket inside a container, wich is something we clearly don't want.

So we need to fix this, and specify in the cnab-runtime spec, how a docker-driver will expose a docker daemon to the invocation image to achieve composition.

I suggest the following rule:

• A docker driver MAY support CNAB composition
• The driver MAY populate the DOCKER_HOST and DOCKER_TLS_* env vars so that the invocation image can consume them to connect to the daemon. (if TLS material is needed, they will be mounted / copied into the container)
• Alternatively the driver MAY mount the /var/run/docker.sock socket or npipe:////./pipe/docker_engine named pipe in the container
• If a docker driver implementation don't want to support CNAB composition, it SHOULD NOT set the DOCKER_HOST env variable nor mount the docker socket or named pipe.

Additionally, should'net we add a field in bundle metadata to explicitly request for access to the Docker engine ? Maybe by introducing Driver specific options in Invocation Images ?

Ping @technosophos @garethr (as for now, it is only a braindump and I think it requires a few feedback iterations before writing a PR)

[simonferquel]

I suppose we can also consider the socket mount in duffle code base as a bug, and don't try to support CNAB composition at all in v1 of the spec. One CNAB author can always ask for a credential for passing connection info to a remote (or local) daemon for CNAB composition.

[technosophos]

Since the spec deliberately does not constrain "image" or "invocation image" to only using Docker, I wouldn't feel right about introducing these into the spec. But I do think we should file this as a bug with Duffle. We're trying to not do CNAB composition at runtime because it introduces a host of new and complex dependency problems.

[garethr]

"it's a bug for Duffle, not details for the spec" was my take as well when this came up internally. It's the right approach, just outside the scope of the spec.

[technosophos]

I'll leave this open to track the issue in Duffle.

[radu-matei]

Closed in cnabio/duffle#661