Transcript

All right, let's talk about the gold standard for secure Docker images. And look, these aren't just some nice to have suggestions. We're talking about the absolute, nonnegotiable rules for building containers that are actually ready for production. Seriously, if you get this stuff wrong, you're basically leaving the front door wide open for trouble. So let's just jump right in with a big question, one that honestly affects pretty much every single one of us using Docker. What do you think is the single biggest, most common security hole you'll find in a container? I mean, take a second. And think about your own Docker files. What comes to mind? You ready for this? The answer is running as root. Yeah, it's that common. By default, containers just run as the root user. And you know what that means, right? It means any little bug in your application suddenly has this massive blast radius. We're talking about the potential for an attacker to exploit that bug right? To your host machines files, maybe even break out of the container completely. It's a huge deal. And that right there brings us to a super important security idea. The principal. Of least privilege. It sounds fancy, but it's really simple. All it means is don't give your A any permissions it doesn't absolutely, positively need to do its job. That's it. And honestly, if you take away just one thing, this should be it. It's the bedrock of container security. OK, so that principle is actually just one piece of a bigger puzzle. Let's quickly run through the five gold standard rules that you really should have in every single Docker configuration you build. O there they are, the big 5 for our walk through today. We're going to 0 in on two of these that give you the biggest bang for your buck, both for security and for efficiency. We're going to get hands on with #2 setting up a non root runtime and #3 building a really small final image. Alright, first U the non root runtime. This is all about implementing that principle of least privilege we just talked about. Let's dive in and see how it's done. So what's our goal here? Well, it's actually a two-part mission. It's not as simple as just switching users. First we need to create a brand new unprivileged user just for our application. And 2nd we have to make sure that new user actually owns the application files. Both steps are crucial. OK, so where do we start? Right inside your Docker file. Step one is to create a new user and a new group for that user to live in. Pretty straightforward. And this is the magic command right here. This run command does its work while the image is being built. It adds a system group, we're calling it app, and then it adds a system user, also called app and boom, puts that user in the group. Simple, clean and effective. OK, user created. Next U when we copy our application code into the image, we need to set the file ownership at the exact same time. This is a neat trick to avoid a whole bunch of permission headaches down the road and check this out. This is one of my favorite little docker features. The normal copy instruction has this awesome flag dash chone. It lets you change the owner of the files as you copy them. So we just tell it to give ownership to our new app user and group. No need for a separate run chown command which is just. Fantastic. Alright, this is the last step for this part, but it is absolutely the most important one. We've got our user, we've got our files owned by that user. Now we have to actually tell Docker, hey, use this person from now on. And it's this simple user app. That's it. This one line tells Docker that everything that comes after it, including when you launch your application, should be run as our new non root app user. Just like that, you've massively reduced your risk. OK, practice 1 is down. Let's move on to our second gold standard, making our final image as small as possible. This isn't just about saving disk space. A smaller image means a smaller attack surface, which is a huge win for security. The whole philosophy here is minimalism. Think of it like packing for a trip. You only want to bring exactly what you need. For a production image, that means just your application and the things it absolutely needs to run. Nothing else. No build tools, no compilers, no extra utilities, not even a shell if you can avoid it. Just the essentials. And this comparison really says it all, doesn't it? On the left, you've got your typical bloated image. It's got all the tools you need for development, but every one of those tools is a potential security risk. On the right, that's our target. A minimal image. It's lean, clean. And gives an attacker almost nothing to work with. Our job is to figure out how to get from that image on the left to the one on the right. O how do we pull that off? Well, it's done with a really powerful pattern that uses a few steps right in our docker file. And the whole thing kicks off with something called a multistage build. This code here shows you the core idea. Look closely, you'll see two from lines. The first one sets up a builder stage. It uses the full Go language image with all the compilers. And tools to build our application but then and this is the cool part the second from line starts a completely fresh super tiny image we're using a desireless image here, which is about as bare bones as you can get then the magic happens with that copy slash from equals builder command it reaches back into that first builder stage and plucks out only the finished application dropping it into our new tiny final image All the build tools get left behind OK so we've walked through running as a non root user and. We've seen how multi stage builds work, So what does it look like when we put it all together in one docker file? And here it is, the final product. This is a great example of a secure docker file that does everything we've talked about. You can see the builder stage right at the top doing the heavy lifting. Then the final stage starts fresh. It creates our app user, copies the compiled code from the builder and uses dash Chone at the same time, and then finally it switches to our non root user right before kicking off the application. It's beautiful. Isn't it? O if we boil all this down to one key take away, it's this quote right here. Seriously think of this as a new policy you can take back to your team. Every single container heading to production needs to run as non root, be built with multi stage builds, and ship only what it absolutely needs. It's clear it's doable and trust me, it makes a huge difference. And that really leaves us with just one last question for you to think about. Take a good, honest look at the containers you're running in production right now. Are they built this way, right? If the answer is no, well, the good news is you now have a perfect road map to fix it.