 Hello. Welcome to the next presentation for the 101 Essentials Cloud Track. This presentation is by Sangram Rath, a multi-cloud professional bringing 15 years of experience to his presentation on container security. After the presentation, there will be some time for Q&A. So feel free to type any questions you may have into the question box that's part of Intrado. Without further ado, here is Sangram. Sangram, we can't hear you, but perhaps we can use the phone bridge instead. Am I audible now? Okay. All right. So hello everyone, and sorry for the technical glitch. Good afternoon, good night, good morning depending on where you are, and welcome to this track on container security 101. Are you sure? Are you sure? Am I audible now? Okay. So again, apologies for that. Hello everyone, and welcome again. Good afternoon, good night, and good morning depending on where you are, and welcome to this track on container security 101. The talk includes some slides and a demo, and we will have some time for Q&A post that. My name is Sangram Rath, and I'm an independent cloud architect and technology advisor currently working with a couple of companies, both are startups, and lately I've been focusing on security, especially assessing security posture of infrastructure, application and data, implementing recommendations and remediation logic, et cetera. I also do a lot of trainings. So some of you, especially if you have, if you're from India, you probably would have seen me somewhere. This session will provide an overview of cloud native security, but focus on container security, covering the challenges and risks that come with using containers. We will then see some common threats and scope and highlight some of the container vulnerabilities that are out there. The talk will finally introduce various tools, mostly open source, and they can be used to provide a layer of protection for your containers. Some of these open source tools also have a paid version that provide additional capabilities. Cloud native computing is the hottest trend in the cloud ecosystem right now and is increasingly becoming the new norm for application development and deployment. At the core of cloud native computing infrastructure are containers, and with the increasing adoption of it, because of the scale of deployment, especially the large scale deployments that we see out there, security has become an important aspect of the adoption strategy. So one of the best practices around security in general, even before you can say, cloud became popular is the layered approach to security, otherwise called as defense in depth approach. The four Cs of cloud native security are basically based around that, and these four layers of cloud native security are code, container, cluster, and cloud. This session will be particularly focused on container security, but just understand that cloud native security cannot be managed by container security alone. So you need to ensure that there are other layers like code, cluster, and cloud, and you're following the recommended security practices around them as well. For example, secure coding practices, checking for code vulnerabilities during development, maintaining security for cluster orchestration, like Kubernetes, Docker swarm, or any other platform that you use, right? And of course, don't forget to secure your hosting platform. The hosting platform could be on cloud, very common nowadays, but make sure your platform is secured as well. In this session, we'll be focusing on the container part of it, but make sure that the other areas are not ignored, right? So you've got the four Cs of cloud native security there. Okay, I still see some chat messages on some people not being able to hear me. Can someone confirm if I'm still audible? Just wanna make sure that it's not a problem for my end. All right, great. So let's move on to quickly look into what containers are before we look into container security, right? Especially for those among us that are new to this term and what the container adoption market looks like today. Why is it that we are looking at container security and why is it so important? In this definition from Docker, a container is a standard unit of software packages of code and all its dependencies. So the application runs quickly and reliably from one computing environment to another, right? The idea of containerization or earlier called as process isolation, right? It's not new and goes back, you can say a decade or more. However, the way we use it today, you find it in every application, mobile applications, you find it in IoT devices, you find it everywhere, right? It's definitely a game changer. And because of this huge adoption of containers in every aspect of technology today, we are looking at security, right? So the problem statement that we're trying to solve with containers is the reliable movement of code or software between compute, storage, network, security environments, while at the same time keeping it light, fast, modular, right? So that's the problem statement we're trying to solve. And we do this by packaging the code and its environment, which includes dependencies, libraries, binaries, configuration files into a single unit, minus the operating system. That's the key here. So containers involve virtualizing the OS and they're popular, there's a growing community and the enterprise adoption of computers is also spiraled over the years. We'll see some numbers here quickly to kind of really prove you that that's true, right? So this report by 451 Research, which was in 2018 states that containers will be a $4.3 billion market by 2020, right? Container adoption is mostly driven by maturity over time, growing community, which I mentioned a couple of times, resources, the amount of learning resources and implementation resources that are available and many enterprise products that are getting built around these containers as well. And not to forget tech giants and high growth startups advocating it, which also builds a sense of trust and confidence for others in similar industries to adopt it. Got some more numbers here. Let's take a look. This is a similar 2019 report by Portworx and it shows that container adoption continues to grow in large enterprises, especially in production environments. So here almost 87% of the people getting surveyed said that they are using containers and of the 87% you have almost 90% people saying they are running container technologies in production, right? And while we are at it, not to forget a survey by CNCF as well that shows that containers, container use in production has increased significantly and you had almost 84% of the people responding to the survey mentioning that they're using containers in production. And this is up roughly 15% from 2018. This is a result of organizations having trust in containers and using them more for production workloads, user-facing applications, customer-facing applications. Yeah, I mean, there has been absolutely a growth in container adoption of lately. At least ever since you had Docker coming in and making container as much more easier to use, I would say that, right? Now on the same lines, when we talk about growing adoption of containers, right? Particularly technologies such as Docker, Kubernetes, OpenShift, this is great and its benefits like faster deployment, scalability, portability has fueled the growth of cloud-native technologies. But this also means that security, management, and monitoring these three areas continue to be an area of concern for many of these large enterprises, especially people running containers in production. Again, looking at a few surveys, not really a lot, but just a couple of them, you will see that container adoption is not without its challenges. And this survey by, again, Portworx along with Aqua Security on over 500 IT professionals shows that security is at 51% is a top challenge for that. Similarly, the CNCF survey also includes challenges that companies have around container security. And you will find that security, challenges around container adoption, I'm sorry, and you'll find that security is on the list. And monitoring is also on the list on FES. So this adoption rate means security is going to be more important than ever. And while it may seem, if you go by the container architecture that they are inherently secure because they provide isolation, how and where you use them introduces a lot of security concerns. And this could be at the OS level, this could be at the application level, this could be at the data level. So as containers are deployed by more and more companies, they are becoming a hot target for hackers. And some may say that container security may not be that much of a concern at the moment because maybe they feel they are running it in a private environment or they feel that their current security is enough. But trust me, there is an increase in the number of threats and vulnerabilities that we have around containers today. And more and more bad exploiters will continue to focus on targeting containers, create container focused exploits and we have to look at security very seriously. So it's a growing priority in container adoption. And if you do it well, it can help you react to security issues faster as well. So with containers being used everywhere today, such as mobile applications, IoT, machine learning, data science, and even databases, it's important to know what kind of container threats are possible. And there's been an increase in the attack on container environments such as Docker and Kubernetes lately. Some of the popular container threads are listed on the slide deck here and I'm going to talk quickly a bit about them. Container malware is gaining popularity. An example of this threat is the Kinseng malware, which runs on Ubuntu. And it's provisioned in a container environment, typically through a misconfigured Docker API. And the malware container, once it is provisioned inside your environment, can actually work as a crypto miner and move laterally and spread the malware misconfigured or other vulnerable containers and hosts as well. Another threat that you will see out there if you search for container threats is cryptojacking. And this involves fraudulent cryptocurrency mining using your computer sources. And it is a lucrative area because you are mining cryptocurrency and you're making currencies out of it, sending it to your wallets. This is also a type of malware and the main work it does is uses your computing capacity. Of course, figuring out less secure machines and infecting them with a container that can mine cryptocurrencies around Ethereum or Monero, for example, and then send the currencies to the wallet of the attackers. Another one that you will probably hear quite a bit from security professionals is the Dirty Cow Container Expert. In this threat, basically the exploit is on the kernel bug to overwrite a program called Set UID in the system. And this allows the user to temporarily elevate the privilege in order to perform a certain task. So by replacing the Set UID program, the attacker can gain root access privilege when the program is executed and basically may be able to do anything. And if you think that just by deleting the containers or removing the infected containers, your threat is removed. That's not true either. Sometimes these threats result in container immutability being broken. So an example that I can talk about is the PASSWD Set UID program in Linux system. Then you've got the escape vulnerability. Again, you know, something that is pretty... You can say that it's one of the top threats. And this involves, you know, Run C, which is a runtime that ties container engines to Linux kernel. And in this threat, an attacker with root-level access inside a malicious container will gain root-level access on the host as well. And they might, you know, be able to perform... They might be able to do that by performing certain privileged tasks as container or execute certain privileged escalation bugs or do certain misconfiguration. There could be various approaches to gaining access to your host, root-level access to host. Docker engine is an example of a container engine that was affected by this and has been patched since. So this is just an example. However, there could be certain container engines that still have this. And if you're using Docker, of course, provided that you've upgraded the Docker engine, you're safe. But again, you know, in a container, the threat vector can be compromised, image compromised, you know, container at runtime or a compromised process. And a lot of these threats kind of are around that. Similarly, if we take a quick look at the types of container vulnerabilities, here's a list. And we'll only talk about a few of them in the subsequent slides in the interest of time and the level of content. But just to quickly introduce them to you, considering this is a one-on-one track, container images are building blocks of containers, right? They are layered, they are made up of other images such as base images. And hence, they are a common source for injecting vulnerabilities, right? If you're using a base image that has vulnerabilities, they tend to be a part of your image as well. Further, it's a common development approach to reuse images, right? Especially open source developments. And hence, you know, it becomes very important that you, you know, check for container image vulnerabilities. Many images may also provide root access within the container that too without a password. So this is a type of misconfiguration scenario. And this can expose containers to vulnerabilities both within the container and in some cases to the host as well. An example of this is the official Alpine Linux docker image that had a blank root password for quite some time. This was found by Cisco Talos researchers in 2019. And this might not be a direct thread depending on what's running inside and how you've configured it, right? But it is definitely a vulnerability, it's definitely a way in which some other vulnerability might be introduced into the container, right? So it's a concern. And there are many such images out there that come with blank passwords, especially blank root passwords, right? Some other vulnerabilities include less secure container engine, less secure orchestrator APIs like Kubernetes APIs, allowing attackers to get into your systems to provision containers, misconfigure, take control of your cluster, right? Or your container environment. Another example that I can talk about here is an incident involving, you know, Tesla. Where hackers gained access to unprotected Kubernetes console. And in a classic example of lateral movement, they found out the S3, Amazon Web Services S3 access credentials to some telemetry data, which was, you know, apparently sensitive data, right? They also, at the same time, while they were at it, they apparently also performed crypto mining. And according to the report, they employed some really sophisticated, evasive maneuvers, you know, to perform the attack. Similarly, privilege escalation involves exploiting vulnerabilities during container runtime. The run C exploit that we spoke about earlier is an example of this. Within a container environment, remember containers can talk to each other, right? Over the overlay network. So a compromised container can actually move laterally and in fact, spread the threat or spread the vulnerability to other containers as well. Right? This is a situation that could lead to, you know, DDoS or SQL injection or cross-site scripting, especially in case of internet exposed containers. Insecure or less secure configurations result in vulnerabilities. This could lead to stealing data and consuming computer sources to do crypto mining, et cetera. So while the value provided by containers is immense, you realize that, you know, there are a lot of threat vectors that are there with containers as well. And we have to have a different approach to securing containers. We cannot use a standard approach that we have for typical infrastructure, right? So reducing attack surface area is very, very important to reduce the possibility of exploits through vulnerabilities and this starts at every layer of the four C's of cloud native security. So it starts from the code. Of course, we are focusing more on containers here, but remember that your aim should be to, you know, reduce the attack surface area. Right? Some examples of common container vulnerabilities. Here you have, you know, some CV numbers just for your reference. And they again are around the different threats and vulnerabilities that we spoke about. Run C root access, remote execution, blank root password, local users gaining privileges by placing a Trojan horse, executing arbitrary code, code injection possibility, right? Attack vulnerability resulting in a read write access to the host file system with root privileges. These are some, you know, common container vulnerabilities. Some are old. Some have a very high threat number in the CV database. While you might be already following certain best practices and many of these container vulnerabilities might not really apply to you, just make sure that you are aware of all of these and you are implementing them and following their recommended security best practices. Within the container security challenges, if we want to just focus on container security challenges, right? Again, taking a look at a look at a survey, I want to point out two things here. One is a vulnerability management and the second is runtime protection. And when we talk about vulnerability management, we're talking about container image vulnerability, right? So these are the top security challenges. This is again a survey by Portworx and Echo security. And, you know, we have those, we have the survey revealing that vulnerability management and runtime protection is in the top three security challenges that come with using containers. So focusing on those two aspects in the next set of slides, let's start with container image security. One of the most important components and, you know, or you can say elements in container security is securing the container images. And because container images are commonly available, they are very popular in reuse. So they focus on reusability and, you know, many popular open source line of distributions are used as a base for these container images. They are an important vector that brings in, you know, vulnerabilities into your application, vulnerabilities into your system. They may result in you using vulnerable system libraries, vulnerable base images and all of that. So a few questions you should be asking yourself in this step in securing container images are, are your container images free from vulnerabilities? So what do you do? You start by using latest images. You run container image vulnerability scans and this should include base images. Prefer certified images published by the vendor itself. Do not pull images without validating authenticity. Do not pull unsigned, you know, docker images or container images in general. Fix vulnerabilities before using them in production. Let's say you have to use a base image and there are some vulnerabilities. It's your responsibility to fix them before you actually run your code in production. So this should be a part of your entire container lifecycle process. Do you trust these images? Right? So this is where signing the images and verifying that the images, you know, are signed by a trusted, you know, a publisher is important. Use signed images, preferably pushed by the publisher and look at the history to see if it has been modified. So that brings me to my next question. Is your image repository or registry secure? Compromising registries is also a very popular, you know, threat. People gain access to your registry and they might be able to change the images or modify the images and add vulnerability to it. So make sure that you secure your registry with username, password, use TLS, use private registry wherever possible, right? These are some things that you can do to ensure that your image repository, your registry is secure. Are you following the least privileged access model? Very important. A container is usually executed as a root user if you don't provide a user value while creating the Docker image. And this could lead to a security issue. So if you really want your container to run as a root user, make sure that, you know, that's actually required. You don't always need a container to run in a, you know, a root user mode, right? When that namespace is mapped to the root user in the running container, the container could potentially result provided there are some misconfigurations or some other vulnerabilities. It could result in, you know, providing root access to the Docker host as well or to the container host as well, right? So don't use a root user unless you really have to. So these are some questions we ask ourselves, especially, you know, while we are talking about when you're thinking about container image security. Again, a quick report by, you know, a company called Snipe. I'm sorry about the typo there. The company provides, you know, fixing and monitoring vulnerabilities, detecting and all of that. And according to them, the top 10 most popular Docker images contain at least 30 vulnerabilities. Similarly, there are posts and I would like to quote a post here by Kenna Security, which is also a company that secure the focus is on data science, you know, to measure and predict cyber risk and all of that. And they state that 20% of the 1,000 most popular Docker containers have no root password. Of course, these are slightly older, you know, you know, surveys, but I want to, you know, stress on the importance of these things, right? And that's why these numbers. And these numbers are alarming. If you have 20% of the, you know, 1,000 most popular Docker images having no root password, you can understand that there is always, and if you have just used them as it is, you have a threat vector there, right? So it shows that security is not to be taken lightly and you got to watch out for these kind of things. Again, make sure that there might be certain use cases for running containers with root privileges, but don't do it unless you really have to. Let's talk about, you know, container runtime security index, right? So we spoke about two things, container image security and container runtime security. They broadly cover almost every security threat or vulnerabilities that we, you know, took some examples earlier. So fresh vulnerabilities always appear, right? You might have done everything. You might have used an image that is free of vulnerabilities. You might have done everything at the core level to ensure that your image is, you know, as per the security recommendations, you followed all the best practices and all of that. But vulnerabilities are not static. You always have fresh vulnerabilities appearing and hackers are always on the lookout to, you know, exploit. And while we may have taken every possible step to ensure our containers are created securely and, you know, there is always, you know, a new vulnerability or threat that could come up and this is where making sure that your container runtime security is also addressed is important. So that you have a better chance of remediating any exploitation that might arise, you know, during container runtime. So some of the things that you should be looking at at this, at this level, you know, and again, this is not a very, you know, fixed list, just some of the things that, you know, out of my experience, I feel should be highlighted here. So this is a list that includes, but it is not limited to, right? Knowing your application behavior, very, very important. Today's applications are modular. Today's applications are decoupled, highly decoupled. You have, you know, serverless and whatnot in today's applications and it's very important to understand, you know, what your application does. If your application is only supposed to make, let's say, a get call to another component, you need to monitor that and any deviation from only the get call should be detected, because that could mean that there might be some security issue during the runtime, right? So knowing your standard application behavior, right, standardizing it and then detecting any deviations through monitoring is an important step here, right? So monitoring plays a key role in container runtime security. Secure your container API access, very important. Orchestrator APIs, container APIs, or today service mesh is very popular. So even service mesh APIs should be secured, right? Because of the complex nature of orchestrators and service mesh, especially, they bring in additional complexity and introduce new attack vectors that might not be there when you just talk about running Docker containers. That's a monitor and secure them. Follow best practices, secure container engine platforms as well. For example, disabled capabilities like, you know, set UID to prevent processes from changing their GID resulting in escalation privilege, right? Use a separate user instead of a privileged user for Docker commands. Use C groups, use namespaces. They also help in avoiding privileged attacks. They're actually a core part of, you know, container runtime products like Docker. Secure your communication between client and server using TLS. Don't forget network security. It's very important. As I mentioned earlier in the talk, containers can actually talk to each other by default over the overlay network. So if you don't want certain containers to talk to each other, use network namespace, use network security policies, right? They are available in many orchestrator platforms like Kubernetes. You may also force network traffic through an IDS IP system for added security, right? So do these things to ensure network within your container platform is secure as well. You don't have containers just talking to each other for no apparent reason. Because today's, you know, hackers and attackers actually look at lateral movement as one of the, you know, approaches. So if they find one vulnerable container and if that container can talk to other containers in your network, that's a very easy, you know, that's an easy thing for them. They can leverage the power, you know, and infect all the containers and use it for their whatever purpose, crypto mining, cryptojacking, you know, accessing some of your secret information that could be inside the containers, databases, whatever, you know, your architecture is made up of. There could be, they might get access to something that you probably would not even have thought of. Or just use your compute resources for their computing needs. On that point, I would also like to mention that do not put sensitive information like username, passwords, tokens, or any similar things, configuration information into your containers as well. Use solutions that can help you retrieve these details programmatically on runtime and encrypt them during transit as well. So you have solutions like Vault from HashiCorp that can be leveraged to dynamically retrieve these secure information certificates, SSH keys, username password and all of that, right? There are similarly other solutions out there as well. Use a multi-stage build and create runtime container images that have a smaller footprint. So you will actually end up, you know, reducing your attack surface area as well. Have only the required modules and dependencies. If you can use container-specific operating systems such as CoreOS, you know, Red Hat Atomic, PrancherOS, there are many out there that can help you, you know, help you implement a container host solution that has a lower footprint. Lower the footprint, lower administration, better security, lower, you know, attack surface area, less number of attack vectors to, you know, address and so on. Keep your host OS up to date, apply latest security patches, all of that. Unauthorized access should be prevented. Use solutions, and these solutions are in-built in Linux. You know, so you can use SE Linux or some containers and orchestrator solutions provide their own security policies or profiling, security profiling as we call it. Use them, right? They don't cost. They're part of most of these products, actually, today. App Armor is another example of a solution that can be used to prevent unauthorized access to containers. So container runtime security could involve a lot of things. It all depends on what your container does, but these are some top things that come to my mind when we talk about container runtime security. Right? So with that, we are kind of, you know, nearing towards the end of the slides. We quickly take a look at some tools that are available to help you protect your containers. Most of these are open source tools, or at least they have an open source or a free version that you can leverage. Of course, for added capabilities, you might want to, you might have to buy subscriptions or something like that. But I would like to make a point here. Security is not cheap and shouldn't be looked at it that way as well. So there might be sometimes a cost to implementing these security solutions. And the more complex your application architecture is and if you require that kind of security at every layer, yes, this adds up to cost. But considering today's threat scenario around technology and considering everything is driven by technology today, especially if you are using containers, it makes sense that you invest in them if it comes to it. So here are some container image security tools. And when you're looking at container image security tools, give a thought to, or when you are analyzing and selecting tools, make sure you see what is the scanning ability? Are they able to scan into the container images? Are they able to scan inside containers? What's their update frequency? How frequently they update their database with the latest vulnerabilities? Do they provide automation for DevOps? We won't really get into a deep dive into DevOps or even talk about it much. But in the end, I will like to just introduce that security should be a part of your entire lifecycle, right from development all the way till release. So use DevOps wherever you can. It helps you in automating your security scanning and these kind of things. It takes off the burden from you, right? And you can rely on the fact that you have a process in place that checks for these things whenever there is a code that is deployed into production. See for tools that provide policy support, policies help you create various security policies. Different containers might require different kinds of security policies, so it's a good idea if you can create various policies and apply them to respective containers, depending on what they do and what kind of security is required for them. Clare, for example, is built by CoreOS and performs static analysis of container vulnerabilities. Anchor Engine provides CVE-based vulnerability reporting. It's DevOps compatible and supports policy-based security. And there is an open-source version, which is the Anchor Engine, of course, that you can use. This app is, again, a benchmark guide and configuration baseline-providing solution. It helps you in ensuring that you follow certain guides and implement security as per certain standard baselines. Similarly, around container runtime security, things that you should be looking at, one very important is real-time monitoring, right? Although there are inbuilt protection mechanisms like control groups and namespace capabilities in container engines like Docker, like we discussed earlier, if you are looking at a tool for container runtime security, look at real-time monitoring capability, access control capability, look at networking monitoring capabilities. Do they provide forensics, which might be important for you to do root cause analysis in some cases? Do they provide compliance and audit? A lot of the companies that I work with, they need tools that provide compliance and audit. They eventually, let's say, build products that are around PCI DSS or HIPAA or maybe conforming to GDPR regulations, whatever the need may be. Sometimes they want these tools to provide some sort of compliance and audit report as well. So SysTig is an example that provides deep system-level capturing and real-time analysis capabilities. And Falco is also an open-source, cloud-native runtime security project by SysTig, which is the de facto threat engine you will find on Kubernetes. So these are some tools that you can look at. There are many out there. I have just picked out some of them that are very popular out there. Again, depending on my work, you might have worked with other tools. And of course, whatever the tool is, just make sure that you look at some of these things and select a tool that works out best for your needs. Some other container security tools. You've got Docker Bench for security. Very good for auditing Docker containers against security benchmarks. They've got the Docker Content Trust, which we use for image signing. You enable this and you will not be able to download unsigned images. You've got Silium Calico that are around network security. They both provide network security policies, by the way, which can help you isolate containers and enforce networking policies for a group of containers, normally a pod or something like that. Then you've got Notary, which is for image signing and separation of roles. That's also an interesting tool that can be used. In fact, all of these have some sort of a free or open source version available. You are good to start with some of these at least initially and doesn't cost you time to look at the security posture of your container engine, both at runtime as well as container image security. With this, I'm at the point where I'll quickly show you a couple of these tools in action. I've got an environment app and a couple of environments up just to save time and show that we're quickly able to see how these tools give you reports and give you vulnerability reports and all of that. We'll take a look at Docker Bench for security for auditing Docker containers. We will also take a look at a demo on how to use Anchor Engine and maybe if time permits, look at a couple of more demos. Pretty close and then there's just one more slide. Then I'll be happy to take any questions you might have. All right. Getting some messages in the chat about some of you not being able to hear me. Again, it'll be great if someone else from the group can quickly confirm if that's the case or maybe you can hear me just quickly. Let me know. I hope I'm still audible to the majority of the audience. All right. I'm getting some all good. It looks like I'll move on to the demo here. We'll be sharing my screen here in a second. Quickly connect some of the sessions here. The first one that we will take a look at is how to run the Docker Bench. I have a machine here that I'm connected to. This is a Docker Swarm cluster. I've got some containers running here and quickly run a container that's available for doing Docker Bench for security auditing. These commands are easily available to you. I just want to quickly show how you can do some things without any cost and look at your security posture. We run a container that scans your host and the containers for... It checks your Docker runtime engine as well and checks your... If you have Docker Swarm, it checks into that as well. It checks your Docker Swarm configuration, Docker security configurations. Container runtime, like I said. Image and build file auditing. Docker Demon configuration file auditing. It does a lot of things. It's very similar to PCI DSS. If you've done that, you've got some security controls and then within those security controls, you've got some subsections. It does all of that based on the Docker Bench for security standard practices, you can say. This is a quick run of the Docker Bench for security. This is version 134 and it checks for a lot of common best practices around deploying Docker containers in production and it is inspired by the CIS Docker Community Edition benchmark, which is version 110. That's your Docker Bench for security. Similarly, if you want to take a look at the Encore engine, right? We'll quickly run some commands there as well. I know I might be running out of time, so I hope I can... If it's still here and looking at this, I hope I can quickly... I've got some containers running here as well and I've got the Encore engine running. There's a command to quickly bring this up. There is an associated Docker compose file as well and then I've got a couple of Docker images, like Node 10, for example. I've downloaded the images beforehand just to save some time. This is roughly around 911 MB. If I had to run the analysis using Encore CLI, I run something like this. This is the URL of the Encore engine running as a container here. You first add the image, wait for the analysis to complete by running the wait command. Your URL, username, password, image, wait, and then the image name and the tag. Then you can look at the vulnerabilities after the analysis is done. The command here is IAM AG VULN. This takes a few seconds and you can see a lot of them. There is severity level as well. If I start with more, you can see some high severity vulnerabilities associated and their equivalent CV numbers as well. You get all the details when you do the analysis through Encore engine. It should be coming in anytime. You can see some high severity vulnerabilities as well. Another example that I was talking about to perform as part of Docker security, container security in general is using Docker content trust. For this, you do export Docker content trust equals to 1. Basically saying that I want to download only trusted images. Then if you try to pull untrusted image, it says that the remote trusted does not exist for the container image. You can either disable content trust and download it if you really have to or you can just, you will only be able to download images that are trusted. These are some examples of how you can check for vulnerabilities or audit your container environment for known vulnerabilities. Then of course fix the problem and rerun them again. These are some of the best practices using Docker Bench for security as part of your container adoption in your enterprises. With that, a quick summary of some of the container best practices. Again, ensure that you use latest images, scan your image for vulnerabilities, use images from trusted repositories, least privileged access, which is very important. Your aim should always be to reduce your attack service area in every way possible and use a gated approach to security. The more layers you have when it comes to security, you have some time before you can actually, before the attackers can actually get through your data. More number of gates or defense in depth approach and container security approach helps a lot, especially when you are attacked. Please make sure you try and implement some of these. A lot of these can be also experimented using sandbox environments. Please play around with it. I want to end by introducing two terms or two words you can say. One is container security must be embedded into your container life cycle. It takes a few times and should not be an afterthought. Hence take a look at how you can leverage DevOps as part of your container security practices. It will make things easier for you in the long run. And second, shift left when it comes to security. It's very important that you do security steps as often as possible and as early as possible in your life cycle. The sooner you do, the less you will have the less threats and less problems you will have later on in your cycle. So thank you for your time and if there are any questions, I'll be happy to take them. I'll quickly take a look at the chat window and see if there are any questions and then read out and address some of them. A couple of questions that I want to point out is are there tools to scan images? We saw some tools. Another question by Unikrishnan was can you please share the slides? Yes, they will be a part of the recorded session. Saravanan had a question, isn't some of the threats addressed by SE Linux? Yes, hardening on the host level. Remember we had the four levels of security and one of the levels was cloud security and basically your host security comes at that level. So any host that you're using to run orchestration platforms or just standalone container engines yes, we follow the hardening approach and SE Linux is definitely something that can help you address some of those issues. I think there are any more questions in the chat window. Do any of you have any more questions? Please feel free to post them in the chat window. I saw this message now. Yes, I ran some commands to run the Docker Bench for security. Some questions by Sven Troy saying you were not able to see anything on the console but sorry about that if you missed them out I felt my screen was being shared so yeah, again there might have been some there might have been some latency when it comes to the refreshing so you might have seen them later. So again just to address some of these concerns here latency between my slides and the demo. Maybe the demo is still running for some of you. Is it good to have production containers and virtual machines? Anders had this question. Yes, in fact, using containers in virtual machines and not running them directly on host actually gives you an added layer of security. So yes, it is good to have production containers and virtual machines. Lawn had a question do you have a recommendation for which container platforms tend to be more secure Kubernetes versus Docker versus anything else? Well, I've had experience working with Kubernetes and a bit on CoreOS and some years back with the Mesos as well platform as well. When you talk about maturity and when you talk about the number of tools available and the compatibility and the amount of you know ease of integration you will find that Kubernetes stands out. So in spite of having inbuilt security options, yes, you have got other tools as well that can be easily integrated or they can be made a part of your container data center whatever you want to call it. Having said this, that's my experience some people might have a different opinion around it, but yes I would say securing pods and all are relatively much simpler and easier and you have a lot of resources around that. Can you point us to a collection of links regarding best practices and tools don't have it right now bookmarked but I would one link forward from Docker that I can quickly share so I'm going to put it on the answer here and there's another one as well, which I have bookmarked from Docker. I'm going to share that. What helps containers run smoothly? That's an interesting question and many things help run containers smoothly but I think the first thing there are a couple of things that I would like to point out one is very important that you choose an orchestration software when you have hundreds and thousands and tens of thousands of containers you need a good orchestrator. Number two, monitoring what monitoring solutions are available and sometimes these orchestration systems have some really good integration for example Kubernetes with Prometheus is a good example of a monitoring solution that would work out really good for you and you need monitoring to run things smoothly for that matter understanding the security posture and where you stand in terms of security at the moment. So monitoring orchestration these are some things that I would say help containers run smoothly. Some people who run complex architectures also might add networking to it but these are some things that I would say do that. Raimar had a question it seems that I will micromanage many of these containers especially the list of CVs is as long as we have seen any advice on practical approach of fixing all these vulnerabilities one of the things that I do is I use latest images and I have deliberately used some older images to show you vulnerabilities so use latest images and use minimal images start something very minimal and add your own layers and of course when you make the final image remove anything else that is not required during the process of so use a multi-stage build process but use latest images and make sure that your application security and data security is well taken care of so even if sometimes you have certain vulnerabilities that get introduced see vulnerabilities will come in and you know even if you have taken an image that has zero vulnerabilities there is no guarantee that these will not appear again in the future so there might be new vulnerabilities but if you have designed your application and data to be secure enough and the communication between them and application seekers and data encryption and transit at rest and all of those you will have a better protection especially when it comes to data breach and you know protecting your data and applications but security is something that you cannot say that you fixed it you know it is always something new around security okay moving on to some more questions yes Christian I hope you saw some of those examples so one way to enforce that you are using only signed images is to enable docker content trust in case you know you are using docker I use you know docker images often or it is a private registry and you use for example notary to sign your images so use docker content trust or use notary to sign your images and that will be your way to enforce okay what is the performance hit for having containers within VMs good question and unfortunately don't have numbers in my head right now it would depend on the virtualization if you have virtualization using platforms that are purpose built for containers running within VMs maybe lightweight once or it depends if you are taking a core OS that does not have a lot of a lot of additional bells and whistles and you know you have a good amount of and the provider is good and your virtualization capabilities your hypervisor all the things come into play I guess whenever I have had this question I have always my answer has always been give me some you know hypervisors that you choose and I am going to do some tests and tell you what it is because compute changes platforms change and you never know they might have been a performance bottleneck you know earlier for example I have seen again this is from my personal experience running containers in VMs in Google is not performance it does not have a lot of performance impact but then you trade off performance versus security so certain containers that require that kind of added gate you might use them in containers in VMs some containers you do not need that added security maybe just that minus the VM security is okay for them you know you can probably benefit from performance like UIs and presentation layers and things like that but I have seen that Google platform is relatively better when it comes to running containers in VMs compared to other platforms I have not done a comparison between Google, AWS and Azure although I have worked on all three of them but that is a good point that you brought in right so moving on to the next question looks like I still have some time recommendation for running Docker daemon as a non-root user yes please you know Michelle had this question try and run Docker daemon as a non-root user and I think Docker has a new feature you know it is called a rootless mode and that is still in preview though please take a look at that I guess that is something it is still in preview though and rootless mode executes the Docker daemon containers inside a user namespace very similar to you know user NS remap mode yes why not and Anders has a question can you use tools like POPET to keep the container update of course you know use DevOps approaches and you can have POPET scripts that are written that regularly you know map or benchmark against a database or something like that and also maybe you know recreate your container images with any added vulnerability fixes and all of that sure yes in fact like I said you know I ended up mentioning that use DevOps as your approach you cannot just remember everything and ensure that security has been checked it is very difficult to do that alright I guess I'm gonna move on back to the front I have hopefully answered all the questions feel free to check me out anywhere you feel like and I'll be happy to answer any more questions you might have alright alright I guess we have no more questions so I thank you for your time especially if you are in one of those time zones where it's either early morning or maybe you know middle of the night like it is for me and you know I'll hopefully talk to you sometime in some other session thank you and all of you have a good day or good night good evening whatever