Meet Alpine Linux, Docker’s Distribution of Choice for Containers
The Alpine Linux distribution was born as a fork of the LEAF (Linux Embedded Appliance Framework) project, which itself was a fork of an extremely tiny distro, the now-defunct Linux Router Project (LRP).
The concept behind Alpine was to create a light and simple firewall/proxy/VPN distro that could run in RAM. “The idea was that the system was installed in memory during boot from a read-only media and that you could remove the boot media once it was booted,” explained Natanael Copa, the creator of Alpine Linux, in an interview.
Alpine Linux in its true sense was created by technical people for technical people. Its target has always been technical people who can fix things themselves and have the technical skills to contribute back.
In 2016 when Docker decided to switch the official Docker image library from Ubuntu to Alpine, Copa joined the company. Docker is the hottest buzzword in the tech industry and this limelight changed things for Alpine Linux as now it’s attracting more beginners.
“There are a fairly wide range of users. Docker uses Alpine both for their production and also in the products they ship. There are other non-profit organizations that use Alpine, including telephone companies, hosting companies,” said Copa.
Beyond Docker, Alpine is also used by many security related projects but these people don’t want to publicly talk about what they are using, so Alpine remains out of the press radar.
One of the advantages of being used by technically advanced projects is that in return, Alpine benefits from technically advanced people who develop and maintain Alpine. “Some of us are sponsored to work on Alpine and some spend our free time to work on it,” said Copa. “Most of us are more interested in coding than to tell the world how good Alpine is.”
These people work for companies and organizations that themselves use Alpine. So there is a very strong symbiotic relationship, which also creates stability and sustainability of the project. “There are various organizations and companies that are helping with funding. Some are sponsoring developers to work on Alpine, for example, Docker, and some are contributing with hardware and infrastructure. For example, Docker supports development, Scaleway provides hosting, Fastly provides the content delivery network, and many others are supporting in different ways,” he said.
Size Does Matter
What made Alpine unique was its size. The smaller size made it extremely secure and efficient. When I asked about the main difference in terms of efficiency between Alpine Linux and the big boys of the Linux world such as Red Hat Enterprise Linux and SUSE Enterprise Linux Server, Copa said, “They are probably more polished and somewhat easier to use (for many things) than Alpine, but I’d still say they are all big and slow compared to Alpine. I mean, ‘apt-get update’ spends almost the same amount of time to update the package index cache as Alpine spends on performing the entire system install or upgrade. ”
He wasn’t just offering a hypothetical; he offered an actual comparison:
|
1 2 3 4 5 6 7 8 9 10 11 |
$ time docker run --rm -it ubuntu sh -c "apt-get update && apt-get install -y gcc" ... real 0m 12.66s user 0m 0.03s sys 0m 0.01s $ time docker run --rm -it alpine sh -c "apk add --no-cache gcc" ... real 0m 4.68s user 0m 0.03s sys 0m 0.00s |
They all have their use cases.
Alpine and Containers: A Match Made in Heaven
Alpine, even though it pre-dates the popularity of Linux containers, compliments the concept of containers very well. “The original goal was to run from RAM, which is kind of a disposable system that gets re-installed every reboot. This matches very well with the disposable container concept,” said Copa.
Alpine supported vserver containers long before namespaces made it to mainline kernel. “We had an alpine-vserver flavor which we used for our own infrastructure. We later replaced this with LXC which does not require any special kernel patch. So we have supported and used containers for a long time,” he said.
When the Docker community was looking for a distro they found that they could make their containers significantly smaller if they used Alpine and that building the Alpine containers takes a fraction of the time compared to other distros.
“This made the Alpine community grow very fast the last 2 years. Even Docker Inc. got the eyes up for Alpine so now Docker sponsors the development of Alpine,” Copa added. “So Alpine Linux is very suitable for containers and has been in the containers game since the very beginning.”
Guts of Alpine
Alpine was originally built with Gentoo, but it is now independent and self-hosting. It uses the Linux kernel (with an unofficial port of grsecurity patch), the musl C library, BusyBox, LibreSSL, and OpenRC.
“We used the Gentoo hardened toolchain originally so we could use the security features that were in Gentoo hardened. We needed the extra hardening since the typical use case was for security devices like VPN and firewalls,” said Copa. “Later we added support for install to disk, but we still support and use the run from RAM style of setup.”
Alpine uses its own package manager called, apk-tools. Don’t confuse it with Android’s .apk format. Here APK stands for Alpine Package Keeper. Alpine has been using “apk-tools” and “.apk” before Google bought Android Inc.
Since Alpine Linux needed to be extremely small, its developers wanted everything to fit in memory so they had to make things as small as possible. In addition to that, “since the system was installed from scratch every reboot we needed a package manager that was fast too,” said Copa.
The Alpine community did extensive studies before writing their own package manager. “We evaluated pacman from Arch Linux, .deb, ipkg, .rpm and others,” said Copa. “The major reason that we ended up with our own is our ‘run-from-ram’ requirement. We needed a fast manager that can set up tmpfs rootfs from initfs.”
Alpine developers also wanted low overhead for installed package database. “Our main requirement was that it should have only a few files as the full state — all others usually had one or more files per installed package,” Copa added.
To deliver packages to users, Alpine uses “aports,” a tree of ported applications for the distro, which a handful of Alpine package maintainers keep up to date with upstream. They build a package repository from this tree and rsync this to the master mirror. Then there is a list of mirror sites that will mirror the repository and end users will use “apk add” to fetch the required packages over HTTP. To ensure security and integrity, the packages are signed and apk add verifies that they haven’t been accidentally or intentionally modified.
Security is Not a Point and Shoot Camera
Recently, we have started to hear a lot about security holes in Linux. Not that Linux is becoming more insecure, just that now it’s used so heavily in critical areas that it is getting the additional eyeballs that it always needed.
However, Copa, like many others, doesn’t look at security in black and white. Copa argued that how security is measured varies from who you ask. “I think one misconception in the industry is that security is all about rolling out security fixes as fast as possible and I think this is because keeping track of CVEs and times when [they are] detected and resolved is the easiest thing to measure. But security is so much more than that,” argued Copa.
While it’s true that keeping up with fixing patches is important, that’s not the only way to secure software. “We do keep track of security vulnerabilities and try hard to ship software that is up-to-date,” said Copa. “I don’t have any statistics on it but I believe we manage to provide fixes relatively fast and I would not be surprised if we are faster than other distros on average. But fixing CVEs in time is far from the only thing we do to maintain security.”
Fixing bugs is a reactionary approach. In addition to that, the Alpine team also takes proactive steps to keep things secure by design. The first step is to keep the core system as small as possible.
Alpine never installs a lot of stuff that users will never use but might be handy. One example is the Bash shell. There is no Bash installed by default; Alpine uses BusyBox Bash as the default shell. As a result, no Alpine systems were affected by the ShellShock Bash vulnerability of 2014.
In addition to keeping the number of pre-installed components low, Alpine adds another layer of security by not enabling things by default. All Alpine does is provide the building blocks, leaving it up to seasoned sysadmins to enable what they need. That’s contrary to what many distros do: they not only install a lot by default, they also enable a lot of things by default. In those cases, the sysadmin has to actually disable things to start with, in order to keep the systems secure.
Alpine is also very conservative when it comes to selecting secure libraries for the core system. As and when needed they also replace libraries if they find something more secure. “We replaced OpenSSL with LibreSSL recently because we think that is a more secure library,” Copa told me. “We use musl libc as the standard C Library, which is a modern C Library that avoids many of the bad design decisions that you find in GNU libc that can give you trouble.”
Alpine also provides sysadmins with a hardened toolchain by default. “This means that stack smashing protection (-fstack-protector), position independent executables, and full RELRO [memory corruption mitigation technique] with bind-now linking are all enabled by default and you will have to explicitly disable them if you cannot use them,” said Copa. “While many other distros have enabled those things for many or most of their packages, we always have them enabled, for every single package, since the very first release of Alpine.”
Another smart move that the Alpine team made from the very first release was to use the grsecurity patch for the kernel. These days they use a non-official fork of it since the patch for stable kernels are not available for the public. This kernel, together with the hardened toolchain, makes it significantly harder to exploit security vulnerabilities.
“All those things together makes Alpine a good choice for those who care about real security and not only just care about nice graphs with a lot of green “OKs” on it,” he said.
Another thing that’s becoming a buzzword these days is automatic updates. But Alpine doesn’t offer any. “We don’t provide automatic updates, but it should be trivial to do it with a Cron job for those who are interested in that,” he said.
He believes that security is ultimately the responsibility for sysadmins because much of it is in the configuration, but the Alpine community wants to provide good defaults and tools to achieve this.
