‫Next one up.
‫This is a big one.
‫Don't run your apps as root in the container
‫if you can avoid it.
‫If I do this real quick, on a little demo
‫here.
‫All right. I've got Docker running,
‫at least I should. All right.
‫And if I just run...
‫If I just run Nginx, right, and I do a
‫docker top on
‫that container.
‫What do we see here?
‫Inside the container, Nginx started
‫a process at root, and then it created
‫a new process as a non root
‫user. See how that user is 101.
‫This is common of a lot of daemon based programs
‫like MySQL, Postgres, Nginx.
‫A lot of them that aren't programming languages will
‫automatically do this. So, this is safe.
‫What this is doing is this is allowing
‫Nginx to spawn off worker processes that don't run as
‫root to do the majority of the work.
‫So, they have one master process that runs as root, but
‫that's not what's accepting connections and doing the
‫majority of the work. Most of that's in these worker
‫processes. They run as a normal user, which means if there
‫is a vulnerability in Nginx, chances are
‫when incoming connections are coming in and someone's
‫trying to exploit the Nginx HTTP protocol,
‫it's going to be locked, or jailed, into this user
‫at...most of the time unless there's a serious
‫vulnerability that's up here.
‫Down here, and then they're limited to what they can
‫do, right. Even if they were to take over that process
‫somehow, they're still limited as the user.
‫So, this is OK.
‫This is still not running as true root inside the
‫container. What I really am talking about is if you were to
‫run a Python app, or a Node
‫app, or something like that where it's a programing
‫language, then that's going to be
‫something that defaults to root because the
‫programming language in the container doesn't know how your
‫program works. It doesn't know what you want it to do.
‫So, it's going to do root by default, and
‫that's more about application compatibility.
‫We might say that we want this to be secure by default, but
‫Docker chose for all these official containers
‫to really run as root for the programming languages.
‫Let's go check that out.
‫Oops. Not that one.
‫Firefox.
‫So if we go, let's say, over to Hub.
‫Let's just do Node.
‫This is common of most languages.
‫I'm just going to pick Node as an example.
‫Inside Node, if
‫I go into one of the Dockerfiles here.
‫Then I search for user.
‫You'll notice that I don't actually find anything.
‫It's only this user add here.
‫You'll notice that it does this, right.
‫It's technically adding a group called Node
‫and it's adding a user called Node.
‫If you search the rest of this file, you realize that it
‫never changes to that user with the stanza U S E R,
‫right.
‫You should see user node in there somewhere as a line.
‫They don't do that because that's your job.
‫So, what you should be doing in your down
‫level Dockerfile. So, any Dockerfile you're creating off
‫of these official images for programming languages,
‫you should be taking advantage of the users they're
‫creating for you. If they're not creating those users, you
‫can create one yourself the same way. You can just steal
‫this little two-line thing and change to whatever the
‫user you want it to be. If it's for Python, you might just
‫call it Python user, whatever.
‫If you're doing that, then
‫the applications you run will not run as root in the
‫container. By default,
‫if you just run any standard Node app, it will use the root
‫user in a container.
‫Why is this so important?
‫Well, two things.
‫One, if someone is able to break through your application
‫and hack into your application and gain access to the file
‫system, if they...if that application is root,
‫then in the container, they can do whatever they want in
‫the container, right. They can write files to the file
‫system. They can install more programs in that container
‫that can run whenever they want in that container.
‫So, we really don't want them to do that.
‫We'd rather them be very limited.
‫So, if your applications support it, you
‫know, do this. You basically make sure that you have the
‫user available.
‫Then I have an example from DockerCon over here.
‫At DockerCon, I had a whole talk on Node.js,
‫and one of the topics was on the user.
‫Let me see if I can find that.
‫See what I did here? It is a pretty simple file.
‫I'm going to link this and put it in.
‫In this Dockerfile.
‫So, in this Dockerfile I have...
‫I didn't create a user because the Node image already
‫created it for me. I'm just changing to user node.
‫Then I'm installing my packages with these two lines,
‫and then later, I'm going to run it.
‫You'll notice that I have to start using the chown option
‫in my copy commands to make sure that my files
‫are now the same user as the user my
‫program will run as. Otherwise, there could be problems,
‫right. My application probably...if
‫it can't read the files, then it can't run it, right.
‫So, I need the changes those permissions.
‫I can do that with a one liner on a copy command.
‫You'll also see up here that I'm creating the directory and
‫chowning it as well so that whenever the app is copied
‫in, I just want to make sure, extra sure, that the
‫permissions are there so that it can write.
‫Because the minute I change this user, then this copy
‫command, or specifically this run command, will run
‫as that user. If it doesn't have permissions
‫to write to the directories, then it's also going to fail.
‫So, the reason that Docker doesn't do this for you is
‫because they know that your things will probably break.
‫So, you need to take these extra steps.
‫But, it's not that hard. It's really not.
‫You can probably do all of this testing in a day, and
‫then you'll want to run your systems through full CI and
‫full testing on your servers because sometimes, and PHP
‫is one of the ones that's bad at this.
‫PHP likes to run a bunch of log files and do a
‫bunch of writing to disk.
‫Really, anything that's allowing user uploads will write to
‫disk. So, you've got to make sure those permissions are
‫correct so that when people are writing files, like let's
‫say they're running a WordPress blog.
‫That WordPress blog will be writing to disk
‫when users upload images into their their blog.
‫You want to make sure those permissions are going to work.
‫So, you're going to have to definitely do some testing.
‫Once you've done that, now your application
‫will not run as root. So, it can't have full control
‫in the container. The other reason you want to do this
‫is if there's a vulnerability in Linux, which is rare,
‫or Docker, which is also very rare, then
‫there's less likelihood that they're going to break out of
‫this container. That's only happened, well, one
‫time that I'm very aware of, and I actually documented a
‫little bit of it down here.
‫Dirty COW. Dirty COW was a vulnerability in
‫Linux that allowed you to get out of
‫a container,
‫right. The changing of your
‫user
‫right here, wouldn't necessarily solve the entire problem,
‫but it certainly didn't hurt that problem.
‫Other vulnerabilities, it would probably protect against.
‫But this is a best practice.
‫I think that if you have a security team, they're kind of
‫going to insist that you don't run things as root.
‫So,
‫you would do that.