‫Moving on from those, we have
‫runtime bad behavior.
‫I won't really talk a lot about this one, but this is the
‫newest one on my list.
‫The Sysdig Falco is a tool that,
‫there are other similar tools, but none that I've seen that
‫are as easy or as designed for containers as Falco.
‫Falco essentially takes
‫a common little list of bad behaviors, or
‫what I would say behaviors that are suspect, right.
‫Things that shouldn't necessarily be happening a lot, like
‫execing into a running container on a production server.
‫Or, copying files into those containers on running servers.
‫Or, bind mounting sensitive data from
‫the host operating system into the container itself,
‫right.
‫They'll show you a little example here on
‫exactly what you do. They're basically running Falco agents
‫on every server and then doing certain behaviors
‫in containers that might be suspicious.
‫The goal of Falco is to audit and log
‫those behaviors for you to basically
‫track any bad behavior and alert on those logs if you need
‫to. You can
‫see them here running some certain things and seeing what
‫the logs are outputting. The coolest part about this is
‫that it comes with a default set.
‫Because a lot of us don't know all the
‫bad behaviors. Like, we don't know everything you could
‫possibly do if you're a bad actor.
‫The nice thing about Falco is it does come with a default
‫list, and then you can add more rules on your own in
‫your applications. You can make custom list, add them to
‫Falco when it runs.
‫That's a free open source tool.
‫That, I would definitely say, is getting more advanced,
‫right. As you can see, this list, as we go down the list,
‫getting more advanced.
‫But, I think that's something that's worth adding to your
‫production servers.
‫Even if you don't monitor those logs constantly and
‫you don't alert on them, just having those logs so
‫that when you have something that's problematic, you
‫can go back and see if there was any behavior and what that
‫behavior was to sort of trace your steps, right.
‫I definitely would put that in your toolkit.
‫Next up is content trust. I don't really have a demo or a
‫way to show content trust because it's a set of tools.
‫Docker provides a lot of them. On making
‫sure that everything in your pipeline, from code signing in
‫your git repos, all the way to making sure in
‫production that only images
‫signed by your team are allowed to run on servers.
‫That whole process is known as content trust.
‫It's a pipeline of trust.
‫It's a pipeline of signing different
‫parts of the tooling, your images, your code to
‫ensure that nothing runs in Docker on your servers unless
‫you specifically allowed it through signing.
‫OK. So, that's a project.
‫That's definitely a project, right?
‫We're getting down to the bottom of this list.
‫When you start talking about secure development and
‫secure deployments, this is one of those more
‫advanced features because it requires your developers to be
‫involved, your security team.
‫It requires code signing, and image signing, which Docker's
‫tooling definitely makes easier, but they're not going to
‫do it all for you. All right. You're going to have to
‫implement these things in your teams.
‫Next up
‫is something that takes a lot of work and may not give you a lot
‫of advantages.
‫That is taking all those default profiles that I
‫talked about earlier and taking all those default profiles
‫of AppArmor, SELinux, Seccomp and "Linux
‫capabilities". Put that in quotes because that's
‫actually a feature in the kernel. There's like 300
‫capabilities or something, and Docker will take certain
‫ones and remove them.
‫But you can change those. You can customize those on the
‫fly. You can actually lock down more or you can open
‫up Docker, depending on your needs.
‫If you learn about your specific applications, if
‫you dive in deep, you
‫can learn about how to lock these down more.
‫You might even find that some of your applications that you
‫buy, or get from open source, like Nginx, they
‫might have custom templates for these tools that
‫you can download and apply specifically when
‫you run that image. Because Docker itself doesn't know
‫what's running in your container. It doesn't know that
‫you're running my MySQL, right. So, it can't apply
‫a MySQL specific policy. But, you might be able to find
‫one. You might be able to create a better one that's a
‫little bit more secure.
‫That's pretty advanced. You have to be pretty
‫knowledgeable about systems, internals and how that all
‫works. But, Docker supports it all.
‫This is a per container feature, which
‫means you can change it for each container you're running,
‫depending on your requirements.
‫Check that out.
‫Your security team will love you for that.
‫If you can get this stuff implemented and not break
‫anything, that's the key. Don't break anything.
‫Your security team will be big fans of that.