Create secure production environment using Docker
Cidel, Andrés
Andrés Cidel - Create secure production environment using Docker Docker is a relatively new technology platform that helps teams develop, deploy and scale applications with greater ease and speed. However, there are doubts about using Docker in production environments. One important reason is that containers don't provide the same security layer as hypervisors do. The purpose of this talk is pointing out that using Docker in production is perfectly valid, not just for develop and CI environments. We'll learn: - How Docker works. - Main risks. - How create and maintain secure images. - How defend containers. - How delimit security risks in containers. - Best practices for running containers.
 Let's welcome Andres Sidel and let's find something new about how to create the production environments, secure production environments using Docker. Hello. Hello. Can you hear me? Yes? Okay. Thanks for coming. First of all, as my mate said, I'm going to talk about Docker security environments, and I'm going to give you some best practices you can use when you use Docker. First of all, who am I? I'm Andres Sidel from Vincorbis, which is a Mexican company, software company, and I'm a full-stack developer. I've been using Docker for two years, almost two years now, but I've been doing some dev operations, automating tasks, managing infrastructure. So nowadays, I don't know what am I. So let's talk about a little bit of the content of this talk. We're going to know how containers works, what is behind the scenes when you use Docker containers. And we're going to list the main concerns that you have to keep in mind when you use Docker, and how to create and maintain security images, because images are the base of security in Docker, and how to limit risk and good practices. This is a lot of tips that we're going to share with you. So how Docker works. The first thing that we have to keep in mind is that containers are not virtual machines. Virtual machines use hypervisor to manage the execution of a guest operating system. So containers are quite different. Containers are a bunch of processes. Containers can run services. You can install packages in those containers. Containers have network interfaces, but they are not virtual machines. They feel like virtual machines, but they are not. Containers are possible because of two feature kernels, which are C groups and namespaces. So what are C groups? So what's this feature? This feature limits accounts and isolates the resources of the host. And if you have CPU memory, this network IO, it says, okay, I'm going to give two gigabytes to this container. I'm going to enable these network features for this container and manage this as a hierarchical groups. All the children of a process is going to have the same limits. And what are namespaces? Namespaces is the feature that isolates containers. The processes will have their own system view. When you use containers, you, for example, do PS in a container, and you're just going to see just the processes that are running in that container. So you can isolate a file system, memory, user, and networking. That's the reason it's like a truth with steroids. Containers are truth with steroids. And then C groups limit how much you can see and namespaces limit what you can see. Okay. And next, what are kernel capabilities? In a traditional unique system, we have two kind of processes, which are privileged processes whose effective user ID is zero. These are the root processes, and privileged processes whose effective user ID is not zero. And these processes are attached to full permission checking based on the process. Permissions, et cetera. And Linux kernel capabilities allows us to find these access control system. For example, a capability, this capability shown, make arbitrary changes of the file. This allows us to change the permissions of files, and we can make these changes in every single file on the system. Okay. If you browse the code of Docker, the source code of Docker, you're going to see a list of capabilities. This is the default list of capabilities that Docker has as default. And if you want to see a list, a complete list of the capabilities that are supported by kernel, by the kernel, that's the URL. And you can study. So what are the main risks when you use Docker? What are the concerns? First of all, the Docker daemon, it requires root privileges when you use the Docker daemon. So if you control the Docker daemon, you will have access to the root. And if you enable the RESTful API, this is not authenticated by default. So if you, if an attacker discovered your API, remember that if you have root access to, well, if you control the Docker daemon, you will have root access or root privileges to in the host. So how can I secure the RESTful API? First of all, you can enable the TLS by using the flag TLS verify when running the daemon. And you can create a CI server and client keys. That's for authentication, but what about authorization? Docker's out of the box authorization is all or nothing. You can do everything or you cannot do nothing. So Docker provides a generic API. So you can create an authorization plugin by yourself and bypass this problem. And escaping. Escaping is another concern. This is caused by allowing privilege operations, not removing all possible capabilities, weak network defaults, and obviously boxing application code. It means that containers sometimes have a lot of capabilities. And if you do, if you add other capabilities that you may not need, this could be a problem. Remember that a user in a container with root capabilities could be wrote in the host. So how can you prevent this? Well, I'm going to explain each item of this list. So first of all, drop capabilities. As we saw capabilities, with capabilities we can perform root operations or operations that requires root privileges. But for example, in this case, in this example, I'm dropping all the capabilities. Basically running a container like this, you can just run a clock, for example. Basically you can do nothing. Drop a single capability. You can drop, for example, a drone. And this container won't be able to change permissions. And you can combine flags, for example, drop all capabilities and add the capabilities that you're going to use. And I think you're going to start asking, how can I know which capabilities I'm going to need? So the answer is you have to keep in mind which capabilities you could use or you can store them. And if you think that you have in your code a process which could use a strange capability and you are not secure, you can run your test. If you have a set of tests, you can run them and see if you need or drop on or add a capability. Remember that containers just have to be containers have to have no more than they need. Okay. And this is more easy. Enable AppArmor. AppArmor is a linear security model which is in charge of secure the operating system and the programs. So AppArmor uses security profiles to create a granular configuration over capabilities for your containers. And then if you are using Ubuntu right now, you probably is installing Ubuntu and it's running. You can check it with this command, AA status. And this is going to list. This command is going to list the profiles that are loaded. And well, once you create your profiles, you can load them with this simple command. And if you want a container with this profile, you just have to indicate what's the name of your profile. And that's all, sometimes it's quite simple. And there is this tool, which is named is Bain. It's used for create profiles in an easy way. And define a user. This or most of the cases is better if you create an user inside your Docker files with the user add command and add a user directive, not your containers with root access. And multiple containers. This is a big topic. This could be another one hour talk, but I'm just going to list the benefits of this approach. Basically the benefits are limiting containers, sorry, limiting attack scenarios, helping prevent compromise your containers, simplifying development, allowing for easy upgrade paths. And it's very easy to run just with the flag grid only. And you can freeze the file system. If you run a container with this flag, and for example, an attacker breaks out the container, the attacker won't be able to write any file or edit any file, nothing. So it will be better. And you can combine it with using volumes. So you can freeze the file system of your container, but you can add a volume and write on that volume. So you can combine these operations. Another big concern is image provenance. So when you use systems that communicate among networks, trust is the central concern. So when you use Docker engine, you pull images and you push images. So how can you verify that you're getting the exact image that the developer has created, or how can you know that the image has not been tampered with? Docker has solved this problem with Docker content trust, which basically signed the images with certificates and using digital signatures. And it's very easy to activate. Just export Docker content trust, and that's all the first operation that you do as a publisher. For example, build run or pull images, and it's going to work with this feature. If you're a publisher and you are using Docker content trust, the first time Docker content trust is going to create the keys. And everything is behind the scenes, so you don't need to worry about nothing. You don't have to learn a special combination of the commands, et cetera. And why Docker uses Docker content trust and not a GPG? Because Docker content trust creates a digital signature with the timestamp. So you can enable it, you can disable other images. For example, this image is not longer available, so you have to download this. So with this approach, you will have the up-to-date images on your containers. And of course, you have to create secure images, which is the next topic. How can you create and maintain secure images? First of all, verify the software, this is very important. You have to verify the authenticity of the software that you are downloading. When you're using package management, this takes care for you, so you don't have to worry too much. But if you are downloaded raw files or binaries, you should use, for example, HTTP ease instead of HTTP. And you have to check for sign files and balick checksums with a GPG, for example, when it comes to third-party repositories. Obviously, you could use this in your batch scripts or your background files, not just Docker, writing better Docker files. And this is important because sometimes if you want to have consistency in your images, it's better to pull the specific tag. For example, from Alpine 3.4 instead of Alpine. And never run as root. Well, this is like the... Tell me, okay. This is important. This is super important. So always add the user directive, so if you use the user directive, maybe you need the user add comment and drop privileges as possible. And if you have to use sudo, don't use sudo, it's better to go through. So you can use minimal base images. Ubuntu and CentOS, for example, have 60 megabytes. And if you use Alpine, it's a minimal base image, it's five megabytes. And you could reduce attack surfaces, complexity, and size of the images. This is an example of using Alpine. With these lines, you can install the Python runtime. Very easy. And APK is the package manager of Alpine. So other best practices, override whenever possible, especially when it comes about security features, the Docker demand and client, the Docker engine, about using Docker with privileged flag. And this flag is going to remove almost all the limits that container have, so provide non-security. I will provide access to the Docker user or the Docker group. As I mentioned, if you have control of the Docker demand, you could have good access in the host. We provide access to the Docker unique socket or the rest API to potentially introduce colors or containers. Especially when you use Jenkins, for example, your Jenkins manage the Docker demand in a certain way, you have to keep in mind this tip. Then using Docker bench security, this as the repo says, have thousands of common best practices around Docker containers in production. It's just a script and it's elevated privilege for running it. Remove said UID and CGID binaries. I'm sure that you're not going to need them in most of the cases. So it's better not having them. When exporting ports or exposing containers to the network, you know, but Docker exposes to all interfaces. So you have to be sure that you are exposing the container, the network, to the right interface. And follow best practices when writing Docker files, on Internet, you're going to find a bunch of information about this topic. And limit the container intercommunication by default. You can communicate with other containers. Meaning if you're not using the flag link, you can send raw packages and limit the memory. This could help you to prevent from those attacks. So we have... This is the guides that I base this presentation on and Docker is working a lot to provide a lot of documentation about security. So thank you for listening and questions. So questions? Hello. So I had a few surprises using Docker with IP tables because it injects certain rules for networking. Do you have any tips on how to deal with that elegantly so I don't write some rules and then notice that Docker is actually bypassing them? Is your container... Is the purpose of your container manage the network or what you're going to... So I had a container, basically I was running Kibana. I just needed to expose Kibana port and limit a bunch of everything else. So I wrote some IP table rules on my host and then I realized that basically Docker had inserted... I wanted the Kibana port to be only accessible from local host and then I noticed that basically my P tables rule saying only from local host except we're being bypassed because Docker inserted its networking rules and they were actually short circuiting my rules. So it seems to be a common problem. Do you know of an elegant solution? It depends of the stack but we can discuss it if you want after the talk. Any more Python specific security issues with Docker? For Python, I've been using Docker with Python for almost one year and I think that this advice applies for almost all languages but especially for Python, it could be... I don't try to create in-mode table containers. So if your code has a vulnerability, you can drop it with the read-only file systems. So that's all. Any other questions? Okay. If not, let's say thank you once more to Andres. Thank you very much. Thank you.
 Let's welcome Andres Sidel and let's find something new about how to create the production environments,  secure production environments using Docker.  Hello.  Hello.  Can you hear me?  Yes?  Okay.  Thanks for coming.  First of all, as my mate said, I'm going to talk about Docker security environments,  and I'm going to give you some best practices you can use when you use Docker.  First of all, who am I?  I'm Andres Sidel from Vincorbis, which is a Mexican company, software company, and I'm  a full-stack developer.  I've been using Docker for two years, almost two years now, but I've been doing some dev  operations, automating tasks, managing infrastructure.  So nowadays, I don't know what am I.  So let's talk about a little bit of the content of this talk.  We're going to know how containers works, what is behind the scenes when you use Docker  containers.  And we're going to list the main concerns that you have to keep in mind when you use  Docker, and how to create and maintain security images, because images are the base of security  in Docker, and how to limit risk and good practices.  This is a lot of tips that we're going to share with you.  So how Docker works.  The first thing that we have to keep in mind is that containers are not virtual machines.  Virtual machines use hypervisor to manage the execution of a guest operating system.  So containers are quite different.  Containers are a bunch of processes.  Containers can run services.  You can install packages in those containers.  Containers have network interfaces, but they are not virtual machines.  They feel like virtual machines, but they are not.  Containers are possible because of two feature kernels, which are C groups and namespaces.  So what are C groups?  So what's this feature?  This feature limits accounts and isolates the resources of the host.  And if you have CPU memory, this network IO, it says, okay, I'm going to give two gigabytes  to this container.  I'm going to enable these network features for this container and manage this as a hierarchical  groups.  All the children of a process is going to have the same limits.  And what are namespaces?  Namespaces is the feature that isolates containers.  The processes will have their own system view.  When you use containers, you, for example, do PS in a container, and you're just going  to see just the processes that are running in that container.  So you can isolate a file system, memory, user, and networking.  That's the reason it's like a truth with steroids.  Containers are truth with steroids.  And then C groups limit how much you can see and namespaces limit what you can see.  Okay.  And next, what are kernel capabilities?  In a traditional unique system, we have two kind of processes, which are privileged processes  whose effective user ID is zero.  These are the root processes, and privileged processes whose effective user ID is not zero.  And these processes are attached to full permission checking based on the process.  Permissions, et cetera.  And Linux kernel capabilities allows us to find these access control system.  For example, a capability, this capability shown, make arbitrary changes of the file.  This allows us to change the permissions of files, and we can make these changes in every  single file on the system.  Okay.  If you browse the code of Docker, the source code of Docker, you're going to see a list  of capabilities.  This is the default list of capabilities that Docker has as default.  And if you want to see a list, a complete list of the capabilities that are supported  by kernel, by the kernel, that's the URL.  And you can study.  So what are the main risks when you use Docker?  What are the concerns?  First of all, the Docker daemon, it requires root privileges when you use the Docker daemon.  So if you control the Docker daemon, you will have access to the root.  And if you enable the RESTful API, this is not authenticated by default.  So if you, if an attacker discovered your API, remember that if you have root access  to, well, if you control the Docker daemon, you will have root access or root privileges  to in the host.  So how can I secure the RESTful API?  First of all, you can enable the TLS by using the flag TLS verify when running the daemon.  And you can create a CI server and client keys.  That's for authentication, but what about authorization?  Docker's out of the box authorization is all or nothing.  You can do everything or you cannot do nothing.  So Docker provides a generic API.  So you can create an authorization plugin by yourself and bypass this problem.  And escaping.  Escaping is another concern.  This is caused by allowing privilege operations, not removing all possible capabilities, weak  network defaults, and obviously boxing application code.  It means that containers sometimes have a lot of capabilities.  And if you do, if you add other capabilities that you may not need, this could be a problem.  Remember that a user in a container with root capabilities could be wrote in the host.  So how can you prevent this?  Well, I'm going to explain each item of this list.  So first of all, drop capabilities.  As we saw capabilities, with capabilities we can perform root operations or operations  that requires root privileges.  But for example, in this case, in this example, I'm dropping all the capabilities.  Basically running a container like this, you can just run a clock, for example.  Basically you can do nothing.  Drop a single capability.  You can drop, for example, a drone.  And this container won't be able to change permissions.  And you can combine flags, for example, drop all capabilities and add the capabilities  that you're going to use.  And I think you're going to start asking, how can I know which capabilities I'm going  to need?  So the answer is you have to keep in mind which capabilities you could use or you can  store them.  And if you think that you have in your code a process which could use a strange capability  and you are not secure, you can run your test.  If you have a set of tests, you can run them and see if you need or drop on or add a capability.  Remember that containers just have to be containers have to have no more than they need.  Okay.  And this is more easy.  Enable AppArmor.  AppArmor is a linear security model which is in charge of secure the operating system  and the programs.  So AppArmor uses security profiles to create a granular configuration over capabilities  for your containers.  And then if you are using Ubuntu right now, you probably is installing Ubuntu and it's  running.  You can check it with this command, AA status.  And this is going to list.  This command is going to list the profiles that are loaded.  And well, once you create your profiles, you can load them with this simple command.  And if you want a container with this profile, you just have to indicate what's the name  of your profile.  And that's all, sometimes it's quite simple.  And there is this tool, which is named is Bain.  It's used for create profiles in an easy way.  And define a user.  This or most of the cases is better if you create an user inside your Docker files with  the user add command and add a user directive, not your containers with root access.  And multiple containers.  This is a big topic.  This could be another one hour talk, but I'm just going to list the benefits of this approach.  Basically the benefits are limiting containers, sorry, limiting attack scenarios, helping  prevent compromise your containers, simplifying development, allowing for easy upgrade paths.  And it's very easy to run just with the flag grid only.  And you can freeze the file system.  If you run a container with this flag, and for example, an attacker breaks out the container,  the attacker won't be able to write any file or edit any file, nothing.  So it will be better.  And you can combine it with using volumes.  So you can freeze the file system of your container, but you can add a volume and write  on that volume.  So you can combine these operations.  Another big concern is image provenance.  So when you use systems that communicate among networks, trust is the central concern.  So when you use Docker engine, you pull images and you push images.  So how can you verify that you're getting the exact image that the developer has created,  or how can you know that the image has not been tampered with?  Docker has solved this problem with Docker content trust, which basically signed the  images with certificates and using digital signatures.  And it's very easy to activate.  Just export Docker content trust, and that's all the first operation that you do as a publisher.  For example, build run or pull images, and it's going to work with this feature.  If you're a publisher and you are using Docker content trust, the first time Docker content  trust is going to create the keys.  And everything is behind the scenes, so you don't need to worry about nothing.  You don't have to learn a special combination of the commands, et cetera.  And why Docker uses Docker content trust and not a GPG?  Because Docker content trust creates a digital signature with the timestamp.  So you can enable it, you can disable other images.  For example, this image is not longer available, so you have to download this.  So with this approach, you will have the up-to-date images on your containers.  And of course, you have to create secure images, which is the next topic.  How can you create and maintain secure images?  First of all, verify the software, this is very important.  You have to verify the authenticity of the software that you are downloading.  When you're using package management, this takes care for you, so you don't have to worry  too much.  But if you are downloaded raw files or binaries, you should use, for example, HTTP ease instead  of HTTP.  And you have to check for sign files and balick checksums with a GPG, for example, when it  comes to third-party repositories.  Obviously, you could use this in your batch scripts or your background files, not just  Docker, writing better Docker files.  And this is important because sometimes if you want to have consistency in your images,  it's better to pull the specific tag.  For example, from Alpine 3.4 instead of Alpine.  And never run as root.  Well, this is like the...  Tell me, okay.  This is important.  This is super important.  So always add the user directive, so if you use the user directive, maybe you need the  user add comment and drop privileges as possible.  And if you have to use sudo, don't use sudo, it's better to go through.  So you can use minimal base images.  Ubuntu and CentOS, for example, have 60 megabytes.  And if you use Alpine, it's a minimal base image, it's five megabytes.  And you could reduce attack surfaces, complexity, and size of the images.  This is an example of using Alpine.  With these lines, you can install the Python runtime.  Very easy.  And APK is the package manager of Alpine.  So other best practices, override whenever possible, especially when it comes about security  features, the Docker demand and client, the Docker engine, about using Docker with privileged  flag.  And this flag is going to remove almost all the limits that container have, so provide  non-security.  I will provide access to the Docker user or the Docker group.  As I mentioned, if you have control of the Docker demand, you could have good access  in the host.  We provide access to the Docker unique socket or the rest API to potentially introduce colors  or containers.  Especially when you use Jenkins, for example, your Jenkins manage the Docker demand in a  certain way, you have to keep in mind this tip.  Then using Docker bench security, this as the repo says, have thousands of common best  practices around Docker containers in production.  It's just a script and it's elevated privilege for running it.  Remove said UID and CGID binaries.  I'm sure that you're not going to need them in most of the cases.  So it's better not having them.  When exporting ports or exposing containers to the network, you know, but Docker exposes  to all interfaces.  So you have to be sure that you are exposing the container, the network, to the right interface.  And follow best practices when writing Docker files, on Internet, you're going to find a  bunch of information about this topic.  And limit the container intercommunication by default.  You can communicate with other containers.  Meaning if you're not using the flag link, you can send raw packages and limit the memory.  This could help you to prevent from those attacks.  So we have...  This is the guides that I base this presentation on and Docker is working a lot to provide a  lot of documentation about security.  So thank you for listening and questions.  So questions?  Hello.  So I had a few surprises using Docker with IP tables because it injects certain rules  for networking.  Do you have any tips on how to deal with that elegantly so I don't write some rules and  then notice that Docker is actually bypassing them?  Is your container...  Is the purpose of your container manage the network or what you're going to...  So I had a container, basically I was running Kibana.  I just needed to expose Kibana port and limit a bunch of everything else.  So I wrote some IP table rules on my host and then I realized that basically Docker had  inserted...  I wanted the Kibana port to be only accessible from local host and then I noticed that basically  my P tables rule saying only from local host except we're being bypassed because Docker  inserted its networking rules and they were actually short circuiting my rules.  So it seems to be a common problem.  Do you know of an elegant solution?  It depends of the stack but we can discuss it if you want after the talk.  Any more Python specific security issues with Docker?  For Python, I've been using Docker with Python for almost one year and I think that this  advice applies for almost all languages but especially for Python, it could be...  I don't try to create in-mode table containers.  So if your code has a vulnerability, you can drop it with the read-only file systems.  So that's all.  Any other questions?  Okay.  If not, let's say thank you once more to Andres.  Thank you very much.  Thank you.
Andres_Cidel_-_Create_secure_production_environment_using_Docker_0_71.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_72_251.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_252_383.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_384_575.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_576_1211.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_1212_4043.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_4044_5111.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_5112_6623.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_6624_8987.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_8988_9179.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_9180_11327.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_11328_15659.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_15660_19175.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_19176_21779.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_21780_25823.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_25824_25895.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_25896_26063.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_26064_28103.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_28104_30347.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_30348_30563.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_30564_31487.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_31488_31691.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_31692_32639.png Andres_Cidel_-_Create_secure_production_environment_using_Docker_32640_37085.png
Let's welcome Andres Sidel and let's find something new about how to create the production environments, secure production environments using Docker. Hello. Hello. Can you hear me? Yes? Okay. Thanks for coming. First of all, as my mate said, I'm going to talk about Docker security environments, and I'm going to give you some best practices you can use when you use Docker. First of all, who am I? I'm Andres Sidel from Vincorbis, which is a Mexican company, software company, and I'm a full-stack developer. I've been using Docker for two years, almost two years now, but I've been doing some dev operations, automating tasks, managing infrastructure. So nowadays, I don't know what am I. So let's talk about a little bit of the content of this talk. We're going to know how containers works, what is behind the scenes when you use Docker containers. And we're going to list the main concerns that you have to keep in mind when you use Docker, and how to create and maintain security images, because images are the base of security in Docker, and how to limit risk and good practices. This is a lot of tips that we're going to share with you. So how Docker works. The first thing that we have to keep in mind is that containers are not virtual machines. Virtual machines use hypervisor to manage the execution of a guest operating system. So containers are quite different. Containers are a bunch of processes. Containers can run services. You can install packages in those containers. Containers have network interfaces, but they are not virtual machines. They feel like virtual machines, but they are not. Containers are possible because of two feature kernels, which are C groups and namespaces. So what are C groups? So what's this feature? This feature limits accounts and isolates the resources of the host. And if you have CPU memory, this network IO, it says, okay, I'm going to give two gigabytes to this container. I'm going to enable these network features for this container and manage this as a hierarchical groups. All the children of a process is going to have the same limits. And what are namespaces? Namespaces is the feature that isolates containers. The processes will have their own system view. When you use containers, you, for example, do PS in a container, and you're just going to see just the processes that are running in that container. So you can isolate a file system, memory, user, and networking. That's the reason it's like a truth with steroids. Containers are truth with steroids. And then C groups limit how much you can see and namespaces limit what you can see. Okay. And next, what are kernel capabilities? In a traditional unique system, we have two kind of processes, which are privileged processes whose effective user ID is zero. These are the root processes, and privileged processes whose effective user ID is not zero. And these processes are attached to full permission checking based on the process. Permissions, et cetera. And Linux kernel capabilities allows us to find these access control system. For example, a capability, this capability shown, make arbitrary changes of the file. This allows us to change the permissions of files, and we can make these changes in every single file on the system. Okay. If you browse the code of Docker, the source code of Docker, you're going to see a list of capabilities. This is the default list of capabilities that Docker has as default. And if you want to see a list, a complete list of the capabilities that are supported by kernel, by the kernel, that's the URL. And you can study. So what are the main risks when you use Docker? What are the concerns? First of all, the Docker daemon, it requires root privileges when you use the Docker daemon. So if you control the Docker daemon, you will have access to the root. And if you enable the RESTful API, this is not authenticated by default. So if you, if an attacker discovered your API, remember that if you have root access to, well, if you control the Docker daemon, you will have root access or root privileges to in the host. So how can I secure the RESTful API? First of all, you can enable the TLS by using the flag TLS verify when running the daemon. And you can create a CI server and client keys. That's for authentication, but what about authorization? Docker's out of the box authorization is all or nothing. You can do everything or you cannot do nothing. So Docker provides a generic API. So you can create an authorization plugin by yourself and bypass this problem. And escaping. Escaping is another concern. This is caused by allowing privilege operations, not removing all possible capabilities, weak network defaults, and obviously boxing application code. It means that containers sometimes have a lot of capabilities. And if you do, if you add other capabilities that you may not need, this could be a problem. Remember that a user in a container with root capabilities could be wrote in the host. So how can you prevent this? Well, I'm going to explain each item of this list. So first of all, drop capabilities. As we saw capabilities, with capabilities we can perform root operations or operations that requires root privileges. But for example, in this case, in this example, I'm dropping all the capabilities. Basically running a container like this, you can just run a clock, for example. Basically you can do nothing. Drop a single capability. You can drop, for example, a drone. And this container won't be able to change permissions. And you can combine flags, for example, drop all capabilities and add the capabilities that you're going to use. And I think you're going to start asking, how can I know which capabilities I'm going to need? So the answer is you have to keep in mind which capabilities you could use or you can store them. And if you think that you have in your code a process which could use a strange capability and you are not secure, you can run your test. If you have a set of tests, you can run them and see if you need or drop on or add a capability. Remember that containers just have to be containers have to have no more than they need. Okay. And this is more easy. Enable AppArmor. AppArmor is a linear security model which is in charge of secure the operating system and the programs. So AppArmor uses security profiles to create a granular configuration over capabilities for your containers. And then if you are using Ubuntu right now, you probably is installing Ubuntu and it's running. You can check it with this command, AA status. And this is going to list. This command is going to list the profiles that are loaded. And well, once you create your profiles, you can load them with this simple command. And if you want a container with this profile, you just have to indicate what's the name of your profile. And that's all, sometimes it's quite simple. And there is this tool, which is named is Bain. It's used for create profiles in an easy way. And define a user. This or most of the cases is better if you create an user inside your Docker files with the user add command and add a user directive, not your containers with root access. And multiple containers. This is a big topic. This could be another one hour talk, but I'm just going to list the benefits of this approach. Basically the benefits are limiting containers, sorry, limiting attack scenarios, helping prevent compromise your containers, simplifying development, allowing for easy upgrade paths. And it's very easy to run just with the flag grid only. And you can freeze the file system. If you run a container with this flag, and for example, an attacker breaks out the container, the attacker won't be able to write any file or edit any file, nothing. So it will be better. And you can combine it with using volumes. So you can freeze the file system of your container, but you can add a volume and write on that volume. So you can combine these operations. Another big concern is image provenance. So when you use systems that communicate among networks, trust is the central concern. So when you use Docker engine, you pull images and you push images. So how can you verify that you're getting the exact image that the developer has created, or how can you know that the image has not been tampered with? Docker has solved this problem with Docker content trust, which basically signed the images with certificates and using digital signatures. And it's very easy to activate. Just export Docker content trust, and that's all the first operation that you do as a publisher. For example, build run or pull images, and it's going to work with this feature. If you're a publisher and you are using Docker content trust, the first time Docker content trust is going to create the keys. And everything is behind the scenes, so you don't need to worry about nothing. You don't have to learn a special combination of the commands, et cetera. And why Docker uses Docker content trust and not a GPG? Because Docker content trust creates a digital signature with the timestamp. So you can enable it, you can disable other images. For example, this image is not longer available, so you have to download this. So with this approach, you will have the up-to-date images on your containers. And of course, you have to create secure images, which is the next topic. How can you create and maintain secure images? First of all, verify the software, this is very important. You have to verify the authenticity of the software that you are downloading. When you're using package management, this takes care for you, so you don't have to worry too much. But if you are downloaded raw files or binaries, you should use, for example, HTTP ease instead of HTTP. And you have to check for sign files and balick checksums with a GPG, for example, when it comes to third-party repositories. Obviously, you could use this in your batch scripts or your background files, not just Docker, writing better Docker files. And this is important because sometimes if you want to have consistency in your images, it's better to pull the specific tag. For example, from Alpine 3.4 instead of Alpine. And never run as root. Well, this is like the... Tell me, okay. This is important. This is super important. So always add the user directive, so if you use the user directive, maybe you need the user add comment and drop privileges as possible. And if you have to use sudo, don't use sudo, it's better to go through. So you can use minimal base images. Ubuntu and CentOS, for example, have 60 megabytes. And if you use Alpine, it's a minimal base image, it's five megabytes. And you could reduce attack surfaces, complexity, and size of the images. This is an example of using Alpine. With these lines, you can install the Python runtime. Very easy. And APK is the package manager of Alpine. So other best practices, override whenever possible, especially when it comes about security features, the Docker demand and client, the Docker engine, about using Docker with privileged flag. And this flag is going to remove almost all the limits that container have, so provide non-security. I will provide access to the Docker user or the Docker group. As I mentioned, if you have control of the Docker demand, you could have good access in the host. We provide access to the Docker unique socket or the rest API to potentially introduce colors or containers. Especially when you use Jenkins, for example, your Jenkins manage the Docker demand in a certain way, you have to keep in mind this tip. Then using Docker bench security, this as the repo says, have thousands of common best practices around Docker containers in production. It's just a script and it's elevated privilege for running it. Remove said UID and CGID binaries. I'm sure that you're not going to need them in most of the cases. So it's better not having them. When exporting ports or exposing containers to the network, you know, but Docker exposes to all interfaces. So you have to be sure that you are exposing the container, the network, to the right interface. And follow best practices when writing Docker files, on Internet, you're going to find a bunch of information about this topic. And limit the container intercommunication by default. You can communicate with other containers. Meaning if you're not using the flag link, you can send raw packages and limit the memory. This could help you to prevent from those attacks. So we have... This is the guides that I base this presentation on and Docker is working a lot to provide a lot of documentation about security. So thank you for listening and questions. So questions? Hello. So I had a few surprises using Docker with IP tables because it injects certain rules for networking. Do you have any tips on how to deal with that elegantly so I don't write some rules and then notice that Docker is actually bypassing them? Is your container... Is the purpose of your container manage the network or what you're going to... So I had a container, basically I was running Kibana. I just needed to expose Kibana port and limit a bunch of everything else. So I wrote some IP table rules on my host and then I realized that basically Docker had inserted... I wanted the Kibana port to be only accessible from local host and then I noticed that basically my P tables rule saying only from local host except we're being bypassed because Docker inserted its networking rules and they were actually short circuiting my rules. So it seems to be a common problem. Do you know of an elegant solution? It depends of the stack but we can discuss it if you want after the talk. Any more Python specific security issues with Docker? For Python, I've been using Docker with Python for almost one year and I think that this advice applies for almost all languages but especially for Python, it could be... I don't try to create in-mode table containers. So if your code has a vulnerability, you can drop it with the read-only file systems. So that's all. Any other questions? Okay. If not, let's say thank you once more to Andres. Thank you very much. Thank you.
something new about how to create the production environments, secure production environments about a little bit of the content of this talk. with you. So how Docker works. The first thing process is going to have the same limits. And you, for example, do PS in a container, and are running in that container. So you can isolate that containers just have to be containers have have to create secure images, which is the next topic. How can you create and maintain secure Then using Docker bench security, this as the practices around Docker containers in production. container... Is the purpose of your container