Are Alpine Base Images More Secure?

Bret Fisher
A free video tutorial from Bret Fisher
Docker Captain and DevOps Sysadmin
4.6 instructor rating • 4 courses • 197,610 students

Learn more from the full course

Docker Mastery: with Kubernetes +Swarm from a Docker Captain

Build, test, deploy containers with the best mega-course on Docker, Kubernetes, Compose, Swarm and Registry using DevOps

19:15:19 of on-demand video • Updated September 2020

  • How to use Docker, Compose and Kubernetes on your machine for better software building and testing.
  • Learn Docker and Kubernetes official tools from an award-winning Docker Captain!
  • Learn faster with included live chat group (21,000 members!) and weekly live Q&A.
  • Gain the skills to build development environments with your code running in containers.
  • Build Swam and Kubernetes clusters for server deployments!
  • Hand's-on with best practices for making Dockerfiles and Compose files like a Pro!
  • Build and publish your own custom images.
  • Create your own custom image registry to store your apps and deploy in corporate environments.
English All right. So something I wanted to talk about this week and I would love to hear your thoughts on this in the comments whether or not you're doing it or you're concerned about it is some great stuff that Dr. captains we're talking about in our select chat a couple of weeks ago I think might even have been last week or the week before but it was more about some articles that came out and one specifically a couple of months ago three or four months ago around container security scanning and what that really means is your images that you're doing inside inside of Docker that are the building blocks for your containers. Those are storage for your app as the dependencies as well. So the nice thing about that image is that it now becomes a really great place to scan for known vulnerabilities or potential security flaws in code and in applications and dependency. So we call that container scanning or image scanning. There's different sort of terminology in the industry but there's lots of scanners out there and there's more than a few. And those all have pros and cons and if you're if this sounds familiar. This is very similar to the old antivirus wars where we had different antivirus scanners that would pick up on different things. But nowadays with container scanning the one that we typically talk about first is using the open database of known. That's the keyword there is known vulnerabilities in open source software primarily open source software but it's not exclusive to open source. It just happens to be mostly open source because that's where we tend to find allow the flaws because we can see the source. So we end up as an industry figuring out where the problems are quicker. So that stuff has a database of known vulnerabilities it's updated all the time. And so there's scanners out there some free some not that will scan your image and its dependencies. So not just your app but also any app to get dependencies that are installed you know things like Open SSL or even curl if there's a vulnerability in that and you have that in your container image. These scanners are supposed to help you find those vulnerabilities so that you can update them and hopefully apply a fix and some interesting conversation came out about an article from this guy Steven and it was around that these scanners all have different pros and cons right some detect problems some detect other problems and they maybe don't all the tech the same thing. But at the end of the day one of the things in Linux they really depend on is the operating system or in this case the base image like you boon to Debian S.O.S. Alpine stuff like that. Those different base images often need to translate where the files are on the system and what program those files relate to maybe like the open source Open SSL libraries for providing SSL to your web servers. So those files will exist on the operating system somewhere in a file path and they all come together in a package and that those vendors need to supply the scanners essentially a translation to figure out for the scanners to find where the packages live. OK. So that's the background. And it turns out that not all operating system distributions of Linux provide that functionality and they don't all provide it as well as others. So this can cause problems if you're going to scan for vulnerabilities. In other words your base image whether it's Ubuntu or S.O.S or Red Hat or alpine that now matters in terms of you being able to scan the complete database of known don't vulnerabilities in that image. All right and one interesting point that I think came at that through this article and by the way I'll throw this article in the live chat. You can check that out. An interesting point that was made is that right now as it is down here at the bottom it talks about the Alpine problem which I think is a pretty interesting discussion around we as container makers. Maybe someone who makes containers or at least is interested in making containers. And if you make those images one of your concerns right is security and security often has you know we try to lump sum everything into it is secure or it is we have done security and that's really not a thing right. We all. If you've been there long enough you know that security is a lot of things and there is no such thing as truly secure. Right. Maybe we always joke that the most secure system is one that's turned off. So when you talk about your software there's lots of things to consider and Alpine is a really great distribution and that provides a base image Alpine Linux and one of the best parts about it is that it's very very minimal it's very small comes in at around 5 Meg which is crazy small compared to something like a boon to or S.O.S. Now you can compare that in the full operating system since but we're really just talking here about the images themselves the container image is not your host OS. I don't want to talk about host OS is I really want to just talk about your base images for your containers because what I see in the industry and we love to talk about this online is what's the cool cool trendy thing that the Zeit Geist of our community has sort of caught on to and I think in the last couple of years Alpine has risen in popularity a lot to do with the fact that it has such a small image for containers so that's a good thing. And if you you know I have even done this but if I Googled you know secure Docker base image if you start looking around there if I just search for the word Alpine it's not showing up on this page. So that was a Google fail but what I would expect to see is people talking about Alpine because a lot of the industry likes to recommend Alpine as a way to get automatic security or better security out of the box. And the reason that we're arguing for that is that is small. So if it's smaller that means less files less potential vulnerabilities less things to pin it to to potentially patch. Right. And this has been something we've been doing for decades back in the Windows 2000 era 2008. I remember when Windows 2008 came out Microsoft had a new version called core that was a smaller version of Windows Server. And at the time one of the biggest arguments was better security through less patching. And so if you in theory if you have less software on the machine then there's less to worry about in terms of patching and potential vulnerabilities. So that's in our Pyne's case that's one of their reasons for arguing that they're more secure but space isn't always the number one factor in fact as an operator as someone who runs servers for a living I don't see this space as cheap. You know 100 meg of this space even if it's times five images is fine to me I don't need to save five hundred megs of space on my servers. What you know typically I'm not backing up full operating systems you're usually focused on application backups most of the time especially now in the cloud where we're not doing image based server backups if that was something that you were ever into. Back in the old days where to do full image backups and so a lot of our backups were just the entire operating system over and over again. Well we don't do that so much I think as an industry especially cloud native nowadays and I think that when we talk about images and size size is not even one of my top three factors really in terms of an image and its quality. So when I look at an image and potential security concerns or whatever or just using of an image whether or not it's a gig or 20 meg at the end of the day I'm not so concerned I just need to plan for that because ultimately it maybe is a cost in storage but that cost is one of the cheapest things on my list of costs right. Humans being the most expensive thing and then other things like computing power in terms of CPE memory networking those are always to me more expensive than disk. So I don't tend to recommend to people to do Alpine out of the gate. In fact if you've ever seen me talk about Docker production you know that one of the things I talk about is sticking with what you know stick with Debian stick with Ubuntu stick with sent OS stay with those images if that's what you're used to because Alpine is a lot different it's got a different package manager it's that different file locations so you're gonna have to end up changing a lot of your app just to use Alpine and in most cases now some cases if you're using go or maybe no J or something you probably don't have to change a lot. But even recently I have seen in just the last year and especially in the last three months I've seen a multiple other indicators for why maybe you shouldn't be using Alpine as your base image and this really isn't about throwing shade at Alpine and saying that outlines bad. It's really about do we really need to do the extra work of implementing Alpine just for the sake of more security and smaller images so I might not my argument is going to be I don't think that's even necessary and if we consider this new sort of discussion around the Alpine problem in this blog article is to say that alpine right now maybe isn't the best place because it's really hard if not impossible to scan for security vulnerabilities in the CV known database that database of common vulnerabilities that you can't actually do that yet with alpine that you and you can do that with some other ones you boon to Debian Red Hat stuff like that. So if you're someone who's going to use a security scanner Alpine is actually a bad thing for you. Another thing I've noticed recently is that alpine sometimes has sneaky problems that sneak up on you in part and in ways you wouldn't expect. I recently had some some students tell me that trying to get Alpine working with node Mohn has known problems. And I did. I didn't I was not aware of this. I didn't test it but people have come back to me and said using Alpine with their no J.S. node mine and Node minus something and no J S is is for using for file monitoring to automatically restart your node app whenever files change. That's really good for development but evidently they've had problems with alpine when they wouldn't have had problems with Ubuntu and Debian and I'm only bringing this up because it's an important factor to consider when you're going to go and implement a new base image. So a lot of people come to me and and say what do you think of Alpine should I switch everything to Alpine. Should I take all of my images that I'm building on Debian or immune to or S.O.S or something else. And should I shift all of those to go to Alpine because I hear it's smaller and more secure and I and my answer honestly nowadays is it's more complicated than that and you probably should consider it but also maybe just not like stick with what you're good at and what you know the scanners work with years probably you can use the default images because all official images that are default from Docker such as let's just go look at the node 1. So the no default images all default to using Debian underneath which is larger slightly larger maybe 80 Meg larger than than the Alpine image but 80 Meg. I mean that's just as a small factor that it's not to me a big motivator unless I'm maybe on some sort of you know IO T device maybe something like that. You know on the edge or something where I have a really small flash drives or something that might be a concern. But if you go look at the default images if you didn't realize this in the background all these default images are you know if you just type Docker run node or duck or run my sequel. Those are all gonna run on Debian by default because that's how Docker was building them to begin with six years ago. But all of these now have Alpine options. So you would maybe say my sequel colon Alpine and use the tag for Alpine and that's fine but it doesn't mean that you automatically get a better experience all the time right. Not all packages are even available in the Alpine package manager. In fact I for my own use I have to keep security tools or different utilities that I have some of them work in Alpine and some just don't. And I quite frankly don't want to go and manually figure out how to build them because they fail to build and I don't still want to troubleshoot that because of different libraries. So I just leave a Debian for most of my tools and I use other ones through Alpine. And at the end of the day I know that almost everything is going to work on Debian out of the box because the app to get package manager or apt apt package manager is sort of like the king of package manager is everything there. If there's a package for something it's probably gonna be an apt. Right. You might not see something in Yum. You might not see it in our Pyne's package manager but it's always going to be an apt and at comes with Debian and Ubuntu and other variants of those base images. So when you're thinking about images and the sum all this up when you're thinking about images and you want to build your base images security is definitely a factor. But one of those if you're really concerned about security is you're going to want to scan your images. So if you're gonna want to do that alpine may be a disadvantage for you. In that case so definitely read this article since I threw it up in the in the text there. Another thing is does the space benefit really matter to you. You know if if you're losing a little bit on the potential security and you're image size doesn't matter as much especially if you're someone who has you know 800 or 900 mag images which are common when you're dealing with things like you know Java or HP and stuff like that. Those are commonly very large images comparative to 80 Meg or a five Meg. So think about that stuff a little bit. Don't just automatically switch all your stuff because you heard outline was more secure. Obviously there's lots of other security advantages to Alpine since it is small. It does have very few potential vulnerabilities in it but it does have vulnerabilities right it's not impervious to software vulnerabilities it's just maybe less so. The Ubuntu and Debian. The last thing I'll say on this is if you have not looked at the other from images such as Ubuntu and Debian those images are getting smaller over time and I'll just show you for example. It is actually little pet peeve of mine because things are getting pulled out of these images and new versions that used to be in old images and that can actually cause problems in your software. For example paying or IP config or maybe even the P S command. Things that were maybe in the image years ago that you were used to are maybe no longer in those default images on current versions and that can be a little bit of a problem if you assumed that they would always be there. So nowadays I've got in the habit of even if I'm using a boon to image out of the box maybe I'm using the default images which use a Debian I will. I will also go through doing an apt get install of even things like you know the P S command for process listing or curl or whatever I might need right paying or something and that's just to make sure that in the future versions if they ever take those things out I will always have them in my image because I've made a custom image installing those. So if I just do a Docker image L S here I don't have a cleaned up machine so no I do. Actually I've only got a couple here so if I do a Docker image pull of let's just do Ubuntu and then let's do debut in and then let's do Alpine because these numbers change all the time. I'm not actually sure what the most frequent numbers are what the current status is so let's do that Docker image less again and. Right so Alpine comes in at five and a half meg pretty crazy right. If you get into the whole reason behind that it's actually pretty cool about how they build static binaries and stuff linked binaries so that doesn't really small. If you look at Ubuntu a boon to three years ago was probably one hundred and twenty Meg. Hundred and thirty Meg at least. And now it's down to eighty seven and the current version of Debian is 1 to 1. Which is weird because you would normally think that a boon to is normally bigger than Debian and I'm not sure that that's changing in the next release of Debian. There's someone in chat probably knows this answer faster than I do but I think there might be version C experimental maybe it's too experimental. I'm just gonna guess that it's smaller and remember while we're doing this that if you're thinking about your as well I might have 100 hundred containers running. Remember that assuming they're all using the same base layer that layer is only taking up one one time on that on the offering system. As long as you keep your image clean by auto pruning them as in as long as you do things like making sure that most of your apps you're running are within one or two versions of the base images so that you're not you don't have all the versions on the server then you're not going to take up a lot of space with this stuff right. All right let's look at experimental. It's actually bigger. That's a bummer. I seem to remember at some point last year reading about a boon to and Debian moving to something and they have their own slim slim there's something a little bit different. It definitely keeps a lot more out of there but you might wonder how these things are getting smaller. It's not because they're zipping them up or compressing them anymore it's that they're actually just pulling out tools that aren't essential or pulling out libraries that are no longer needed for those core tools. And that's why things like P.S. and paying and kernel and other utilities are disappearing from these images. So just be wary of that all right. So I think it's a great discussion and I look forward to hearing your comments and reading your comments about this in this. I'm actually planning on updates to a couple of my courses to talk about this and give a little bit more information on Alpine and why when and why you may want to choose it over a different version of a base image because it is a good discussion and there's obviously lots to talk about lots of different reasons for choosing a base image over another one.