They mention that in the video. It's an easy way currently to get built packages.
Bazel has plans on their roadmap (https://www.bazel.build/roadmap.html) to open-source rules for common packages ("Repository of BUILD files for third party OSS libraries open to the community") as a P2 for v1.0. This would presumably switch to using those when they're available.
Note that apt is not actually installed inside the container. Bazel just has a rule that knows how to unpack a deb.
It's not just "an easy way to get built packages". It makes this project trivially easy. No need for Bazel, you can do what this project does with a small shell script.
I'm a bit disappointed to see Google releasing a project which ultimately is nothing more than a helpful API around Debian, and claiming it's some exciting new thing "minus the operating system". The README doesn't credit Debian at all.
We should definitely credit Debian more in the readme, but note that the existing package manager rules are actually a bit decoupled from the distroless images themselves, via bazel.
We happen to build these base images with the Debian rules, but we plan to add support for more package managers soon.
You'll be able to start from our base image and install packages via yum/dnf/nix/whatever, or start from a different, more standard base image and install package via bazel.
Disclosure: I'm one of the TLs working on this project.
You don't find it a bit odd that a project built using distribution packages, with distribution package managers, with (eventually) a choice between which of several distributions to use, is called "Distroless"?
It's also pretty weird if you do start to "support" Nix, considering Nix already is capable of building the same kind of distroless Docker images on its own, in a much more rigorous way. That is, Nix tracks and builds the entire dependency tree instead of just using existing binaries, and has a uniform system for expressing dependencies on components. This allows, for example, using multiple different languages in the same container, which it doesn't look like Distroless can do?
The way that this project would be genuinely interesting is if you were actually building the system from scratch with Bazel, rather than using existing black-box Debian binary packages. That would be like what Nix and Guix are already capable of, but it would be interesting to get some competition in that space from a different class of tool. Of course I don't know if Bazel is even capable of doing that and producing an image, maybe a large opaque "distroless" base runtime is the finest level of dependency resolution it's capable of, in this area?
