I like it 👍 cc @justincormack

Overall LGTM

Wondering if this should be --privileged or another flag. Although I guess they're interchangeable: if you have access to docker you can easily become privileged, and if you're privileged you can get access to the docker socket anyway.

/cc @diogomonica

@aluzzardi ya, it should be another flag as well, waiting for @justincormack to remind me of the good flag name that he thought of, but for testing right now we can add this with privileged containers as it fits the number 1 use case.

earlier discussion #9135 and #9135 (comment) 😇

@crosbymichael what changed? :)

Overall, I'm a bit confused; is this PR for introspection or for controlling docker? For introspection, I'd expect a container to be able to obtain information about itself (published ports on the host, labels, ...?)

For controlling docker, this makes sense, but various discussions in the past lead to a conclusion that we should not do this without fine-grained control over what access the container gets. For example, there's many use-cases of containers that only need access to docker events, without the need to be able to control docker. Currently those bind-mount the docker socket (which is obviously insecure), some things from the top of my head;

• being able to listen to a (filtered) set of docker events (specific type of events, or only events for specific containers / services), and (related) being able to inspect the source of that event
• getting access to docker stats (filtered?)

If we decide on providing full access by default, changing that to a limited set may be complicated in future. I'd far more like a limited introspection API to start with, and opening up more features when needed.

I really don't like connecting this to --privileged, I think --privileged in general was a bad decision (I think @jpetazzo even mentioned he wanted to call it --insecure at first); we discourage people to use --privileged because it's adding way too much privileges; adding more features to it only seems to encourage people to use it (because it's convenient).

Just my 0.02c.

TL;DR; I really like having an introspection API as a feature, but in this form, I don't see it as an improvement over what we currently have

Won't this break anyone starting docker daemon in a container?

@justincormack what was the flag name that you were thinking about for this feature ?

@crosbymichael I forget, its annoying me...

The janky failure looks real, read only rootfs.

@cpuguy83 comment is an issue I think - either we should put the introspection socket on a different path (ugh) or make it optional.

when we figureout a good flag name i'll just remove this from --privileged

For the flag name, given it's just a socket to the daemon and not specifically introspection per se, why not call it as such?
Something like --daemon-socket /path/to/socket (or something along those lines).

I'd prefer a flag that lets us extend this feature in the future:

--cap-add DOCKER_PRIVILEGED_DAEMON
--docker-cap-add PRIVILEGED_DAEMON
--security-opt docker=privileged-daemon

@ibuildthecloud have you seen this? Do you have any comments/concerns?

Lets close this until we have a better idea on what people expect and want