www.youtube.com
WHY 2025 - Containing the Horror — A Critique on Docker & Co
Those are functions inside the kernel that do limit um a processes capabilities. {ts:352} um effectively what they do is they do provide namespaces. The Linux kernel does not understand containers that there is a structure called containers that is I believe related to memory management not these containers. {ts:369} Now our cgroups advanced quite fairly and are the most driving projects have proper prop probably properly been docker and systemd. … We haven't finished. There is one key part missing to get Docker really working for us. That is our current user needs to be able to access the Docker communication check which is {ts:840} uh a Unix domain socket. It it's meant to never leave the system and that is quite for a reason. Docker by default runs as root. … That goes horribly wrong if there are any dependencies you need to update because then you need to rebuild the container and in order to do {ts:1297} that you would actually need to create a new software version. So this is the way to go. Please adopt it. Oh, and in general, uh the these labels are are namespaced with orc.open containers. … Point here not being oh that doesn't work. Uh point being it needs to be implemented correctly. So uh this one entry point thing has turned into a bit of a problem uh because there could be some complex tasks hidden {ts:1566} in there and uh if that whatever the entry point is if that process vanishes so does your container. … Think of the dam tools and and x and whatnot. But this is ah I'm on the edge. Point being it's not quite working out. Um what is really infuriating is we do need to to {ts:1686} observe the the process we're running inside our containers. There are three file descriptors predefined that is very very Unix. … You you see a version field here. Um if you execute this, you will get a warning {ts:1827} that this has been deprecated for good reason. Um, I mentioned in the introduction I I used to do weird things with containers and I did need some more exotic features and uh, yes, the version field. {ts:1846} The magic about it is if you modify it, you may lose access to some features. Oh, that's quite simple. You may think, well, you you change it perhaps down. No, no, no, no, no. you advance the version field and suddenly your your docker composer is no longer valid. {ts:1871} Now I would like to ask the audience uh who of you is inspecting docker compos files if they get them from third parties. Okay, that's me. I'll take that answer. Yes. Um well I I do because a surprising number of times {ts:1891} there there's very questionable things in those are I think the most popular are um needless opening of ports that that is going to to compromise your system.
Related Pain Points4件
Docker Compose security audit and third-party file inspection
7Third-party Docker Compose files often contain security issues like unnecessary port exposures that compromise systems. Developers must manually inspect every file, but no tooling provides automated security validation.
Container entrypoint complexity and process termination
7Complex tasks hidden in single entrypoints cause containers to terminate unexpectedly. If the entrypoint process dies, the entire container fails, making debugging difficult and requiring workarounds.
Docker socket access and privilege escalation risks
7Docker runs as root by default and requires Unix domain socket access for communication. This creates privilege escalation risks and security considerations that developers must understand but are not well-documented.
Docker Compose version field incompatibility
6Modifying the Docker Compose version field can silently disable features. Advancing the version makes previously valid compose files invalid, and there's no clear migration path or warning system.