Jérôme Petazzoni

Well fwiw software titles are bs. I really liked this article[1] where (among other things) they say:

> The primary skill of senior engineers is to train junior engineers. If you’re senior with no junior around, you’re not senior.

and

> Under that lens, the term “junior” just means “someone who has done less, and/or has less experience with, a specific task or tasks in a specific domain”, by contrast with “senior”. In other words, junior/senior is domain-dependent and team-dependent: we can be senior in one field (e.g. databases, containers), junior in another (e.g. frontend, machine learning). We can be senior relative to one team, and junior relative to another.

To suggest that you're not a senior developer because you take you're effected negatively by a lot of context switching is just blaming your manager's problems on you. Using a situational[2] senior position, you surely would meet the requirements. Note that neither of those deal with iteration speed or context switching, what a stupid metric.

Maybe you would do better in an actual senior role where you're doing more mentoring/overseeing rather than direct coding and bouncing around in tons of different code bases.

[1]: http://jpetazzo.github.io/2018/08/15/junior-senior-mentor/

[2]: https://en.wikipedia.org/wiki/Situational_leadership_theory

Hmm, thought for sure I'd searched your exactly quote, but I apologize that I missed it.

It seems the author of the article in question replied to my comment as well, and it's worth noting because his intent is (more or less) what I got out of reading the post [1]. I don't find it misleading. I think your point of contention may therefore be with the interchange between application and process as synonyms throughout the post. By implication, I took it to mean application in the context of a single cohesive unit (maybe not just simply a process, though it can be) that is run via a supervisor or alone.

(That said, using LXC directly is something of an exercise in frustration as the CLI tools are a bit... kludgy--Docker is far more polished.)

> You can put sshd in your docker container, you can run init scripts.

I seem to recall that running sshd from a Docker instance isn't exactly the intended use case of Docker [2] and is generally frowned upon.

[1] https://news.ycombinator.com/item?id=8310276

[2] http://jpetazzo.github.io/2014/06/23/docker-ssh-considered-evil/

I don't spend a lot of time on those comparison-style charts if I'm honest, but that is good (and valid) feedback for them. I also hadn't heard of it, I discovered sysbox via jpettazo's updated post at https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/, he's an advisor of nestybox the company that develops sysbox.

For the CI/CD usecase on AWS, sysbox presented the right balance of trade-offs between something like Firecracker (which would require bare metal hosts on AWS) and the docker containers that already existed. We specifically need to run privileged containers so that we could run docker-in-docker for CI workloads, so rootless docker or podman wouldn't have helped. Sysbox lets us do that with a significant improvement in security to just running privileged docker containers as most CI environments end up doing.

Just switching their docker-in-docker CI job containers to sysbox would have mitigated 4 of the compromises from the article with nearly zero other configuration changes.

This is where it comes from and that's probably why it isn't explained in the post: https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion

It seems like if the author(s) of docker-letsencrypt-nginx-proxy-companion had assumed something like docker compose or kubernetes that neatly handles sharing volumes between containers, they probably wouldn't have made the mistake of giving a docker container access to docker for such a trivial use.

I disagree that there's never a good reason to do this though. A docker control panel, or a CI or FaaS that spawns docker containers, can be a good reason to do this. https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/

BTW there's no escaping the container when you're doing this intentionally.

Docker has explicit recommendations for enabling control of the daemon from a privileged container, for example to have Jenkins in a container adjacent to the containers it is manipulating. Mentioned in [run command docs](https://docs.docker.com/engine/reference/commandline/run/#/mount-volume--v---read-only) and [discussed at length](https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/) by senior engineer Jérôme Petazzoni.

From the description, this particular vulnerability (TLS certs mounted to each guest container) seems to have come from an earnest alternative implementation of the same pattern, without considering how that would be inappropriate on a shared host.

Docker-in-Docker is a different thing than bind mounting the socket. The former runs a new docker daemon in a container, the latter just talks to the host's socket. Anyway, https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/ tells it straight from the horse's mouth. It appears you may not even need privileged containers to pull it off nowadays, but the author still lists several more footguns.

Landlock is an all right start at unprivileged restrictions, but yeah, doesn't seem anywhere near as nice as pledge() and unveil().