 Okay. Hello all. Welcome to DevCon QS. And I'm here to present you on the topic of Container Security Automation with Ansible. Okay. So a little about me is my name is Sumit Jaswar. I'm currently working as a senior software engineer in Ansible Content Team, where currently I'm largely focusing on Ansible security content. And previous to this, I was actually contributing towards a networking project and Ansible Core as well. So as you can see, my GitHub and IRC handle is J-U-S-T-J-I-S. And my email ID is Jaswar at fethad.com. So at any point of time, if you feel any, if you have any query you want to reach out to me, either you can ping me over IRC or you can directly mail me on this particular mail ID. Okay. So today's agenda is very straightforward with respect to Container Security. So the first one is understanding continuous security concept. Second one is can using Ansible Automation Platform and continuing on understanding terminology for identifying vulnerabilities, automated vulnerability assessment for Docker container using Ansible. And then the schedules can using Ansible Automation Platform for Docker security and then a working demo for two of the tools that we can utilize in our Container Security environment. Okay. So the first one is understanding continuous security concepts. And in this, the key approach is to evolve out of DevOps and the idea of immutable infrastructure. It also means that every time there is a need for a runtime change, either in application code or a configuration, the containers are built and deployed again and the existing ones are turned on. And this allows for predictability, resilience and simplifies deployment of choice at runtime. And because of this, there is no surprise that many operation teams are moving towards this particular idea. And with this, the questions of when these containers should be tested for security and compliance are also answered. And by embracing the entire process of continuous security and scanning and monitoring, you can automate a variety of workloads and workflow basically. So what are the best practices that we need to take care and we need to keep in mind for the continuous security is the first one is we should ensure that there are no vulnerability in the container build. And we are re-scanning the images deployed on production systems. And also third one, the most important one for my prospects can be rebuilding of images instead of passing the particular images. And how in this particular scenario, Ansible and Ansible Automation Platform can help. So as you know, Ansible Security operation is not coming up with a security solution or it's not a security product. It basically comes up with the integration and with the integration of the vendors that are there in the security space, we come up with the integration and then try to resolve the use case using Ansible standpoints. So the first one is automating vulnerability standards that are currently there in the market, which is StackerOx, Accra Security, Anchor. And this enables the programmatic scanning as well. And this helps in automating runtime production tools to ensure images don't change during the runtime. So the continuous security scanning requires us to manage it in a software like Ansible Automation Platform. While most of the distance tool can be used by scanning and maintaining a benchmark for security, we should think about the entire process of the incident response and thread detection as a workflow. So Ansible Security initiative can actually help in either preparation, detection analysis, containment, eradication and recovery, and also can help in post incident activity. So before moving forward, basically I want to go over the basic terminology which is currently used for identifying vulnerabilities. So these are the common terminology that I've included in this presentation and are part of this list. The first one is CVE, which is actually a list of record and its full form is common vulnerability and exposure. And this list of record is that where each contains an identification number, a description, and at least one public reference for publicly known cyber security and vulnerability, basically. So the second one is open vulnerability and assessment language, which is oval. And it's an international information security community standard to promote open and publicly available security contents. Next comes the common weakness enumeration, which is CWE. So CWE is a category system for software weakness and vulnerability. It is basically sustained by a community project with the goals of understanding flaws in software and creating automated tools that can be used to identify, fix, and prevent those flaws, basically. So the last one is national vulnerability database. This data enables automation of vulnerability management, security measurements and compliance. And it's also a US government vulnerability management database which is available for public and can be used in XML format. So there are many different ways for evaluating security of containers, right? So containers, as you know, in this current scenario, containers are everywhere. And below are the basic tools that can be used to help in achieving continuous security and as well as hard in the your container environment or the community's environment. So the first one that I've included in this presentation is the Dockerbench, which is actually a shell script. And it is used to perform checks based on your Center for Information Security Database, which is CIS. The second one is Clare, which is actually a static or based static analysis based tool. And it has also helped to perform vulnerability analysis based on the CVE database. So the third part of the tools is Stackerox, Aquasec, or Anchor. So these are more elaborated tools, which actually exposes plenty of tools within. And those all come together to actually automate a workflow in the container security world. So it's basically a platform to security evaluation and helps make runtime policy decisions. Another one is Aquasec-Crivy. And it's basically a simple and comprehensive vulnerability scanner for containers. So the last one is OS Query, which is an OS instrumentation framework for OS analytics to do the HIDs type of activities. Okay. So the first one in the list was Dockerbench for security, which I told you guys that it's a shell script to perform multiple checks against the Docker container environment. So the Dockerbench for security is basically a script that checks for dozens of common best practices around deploying containers in productions. And these sets are all automated and are inspired by CIS Dockerbench. So there are what all criteria is a document checks for. It can actually checks for your host configuration. It can check for your Docker demon configuration and files. It can check for your Docker container images. It helps in checking the Docker rent times also helps in checking the Docker security operations. And last but not the least Docker swarm configuration as well. So I'll be showing over the working demo how you can use Dockerbench in your environment using Ansible. So I'll be just going over the working demo at the last of these presentations after discussing all the tools. So stay tuned. So the second one is Clare. So Clare allows us to perform static vulnerability analysis against containers by checking with the existing vulnerability database, which is in this case, ACVE. It also allows to perform voluntary checks against our Docker container images using the Clare database. If you want to have more details, it can be found over your GitHub repo of Clare, which is github.com. Or OS Clare. And Clare is also an open source project, which is a very good from container security world. And if you want to have like if you want to contribute to the project, we can directly do that. So it also ingests vulnerability made out of metadata from a complicated set of sources. It helps clients to use Clare API to index their container images and can match it against those vulnerabilities. And the last point is Clare scanner, which actually can trigger a simple scan against a container based on certain events to check for existing vulnerabilities. So I've included a playbook on run result from Clare. And I have done that because Clare installation and its setup is big complex. So I didn't want to come like run the entire setup and run that particular check during the work, working demo, because it could have taken too much of time. So here it is. You can see the playbook where I'm trying to scan the containers over local host. And I'm not trying to gather any facts. The variables I have used is first one input is image to scan, which is in which in this case, I'm currently using Debian SID. And I have created a Clare server, which is at this particular IP and port. So the first task is downloading and setting up the Clare scanner binary. So I've given the get URL module on various URL and destination. So I'm downloading from this particular URL and trying to copy to destination folder. Then I'm trying to scan that particular image, which I have used in variables, which is Debian SID in this case, SID. And I'm trying to fire the command player scanner on the entire command. And then I'm trying to register the scan output and trying to download the report locally and basically use that particular output to show the actual result. On the right hand side, you can see the result of the report. And you can see the image that I have scanned is Debian SID. And what are the unapproved CVs there is currently? And what are the vulnerability that has the particular container has? So that is how you can use Clare. And actually, it helps in static analysis for your container, like for your container. Now I'm just scheduled scan using Ansible automation platform for Docker security. So basically, in case of continuous security practice, you'll have to do everything in a repetitive world, in a repetitive task sort of manner, where you are planning, doing, starting and acting at the same time, and you are doing it continuously. That's how you can achieve your continuous security practice. So and by following standard checklists and benchmark, and using Ansible automation platform to execute them on the containers, we can actually achieve this. And we can check for security issues and act on them basically. So the first one, as I talked about was StackRocs, which is actually, which actually helps in continuous hardening, which helps in continuous hardening, automatically. So StackRocs basically provides the security across the container lifecycle, and StackRocs container security platform reduces the attack surface as well. It also ensures compliance and stop attacks. So and StackRocs leverages the benefit of Kubernetes native approach to security. And it's basically works on three basic principles, which is this a context where StackRocs add context container data using declarative data in Kubernetes. And it also increases the risk profiling, vulnerability management, runtime detection, and your overall visibility. And the second one is your native enforcement, which actually helps in policy enforcement. And here is StackRocs leverages Kubernetes built-in controls, which actually help in minimizing the operational risk of using third-party inline proxying or blocking solutions. And it also helps in continuous security and continuous hardening basically. So it actually helps in continuously monitoring and minimizing the attack surface, as StackRocs uses knowledge from runtime behavior to all the subsequent builds and deployments and basically vice versa thing. So the StackRocs focuses on Kubernetes helps, develops, and security team operationalized security simplifying the process of protecting and cloud native application standards. Okay, so StackRocs exposes Hugh Blinter as a tool, which actually is a static analysis too. And that checks Kubernetes YAML file and Helm charts to ensure the application represented in them adheres to the best practices. So it analyzes Kubernetes YAML and checks them against a variety of best practices with a focus on production readiness and basically security. So Hugh Blinter is configurable, okay? So if you want to enable and disable checks, we can do that. Also, if you want to create your own, if you want to come up with your own custom checks, you can do that because from company to company and organization to organization, rule might differ. So we can make a custom rule and apply in Hugh Blinter. And Hugh Blinter also helps in giving recommendation whenever there is a failure in the lyncher. Okay, so Anchor Engine is an open source project, which actually provides a centralized service of inspection analysis and certification of container images. And Anchor Engine can be accessed directly through RESTful APIs or Anchor CLI. But in our case, we will most probably go through a REST API. And the Anchor Engine is provided as a data image that can be run standalone or within orchestration platforms. And how it helps achieving the system hardening or the container hardening is via policy evaluation operations, your image operation, image operation checks, your policy operation checks, your registry operation checks, your subscription operation checks, and your system operation checks. Okay, so another tool is Accoset Cubebench for Center for Internet Security Benchmark scan. And Cubebench is a tool that checks whether Kubernetes is deployed securely by running the text documented in the CIS Kubernetes benchmark. And basically CIS is an organization which actually provides best practices for secure configuration of the target system. And it actually covers plenty of technology of which containers and Kubernetes is part of it. And it is developed through unique consensus based approach, which actually comprises of cyber security professional and subject matter experts around the world. And it also checks and verify Kubernetes deploy as for Kubernetes best practices. So what are the advantages of Cubebench? It's an open source tool. It actually performs automated assessment. It checks and verify for Kubernetes security best practices. It's installed directly or can be installed by a Docker container as well. Okay, so as I was talking about Truby before, so Truby is a simple and very easy to use tool. And it's also a static analysis tool. And Truby actually detects vulnerability of OS packages, basically your container OS packages like Alpine, REL, CentOS, etc. And it also helps in identifying the application dependencies. And Truby is easy to use. And if we just install and if you just install the binary, we can just directly consume it for a standing. And all we need to do for a standing is to specify a target such as image name of the container based. So that's why it's one of the most used tool in the container security world. And because because of its advantages like open source, it's an open source target, simple, it's fast, it can be easily installed. It actually helps in detecting comprehensive vulnerabilities. It has high accuracy, high accuracy, and it can easily be fitted in your desktop pipeline. It actually supports multiple formats as well. Okay, so now we'll discuss about schedule scan for file integrity checks. And this is basically hostable monitoring using Ansible automation platform. And the main advantage of being able to execute command on the host using Ansible is the ability to get the internal system information like file ashes, your network connection details, your list of learning processes. So it can basically act as a light based host based intrusion detection system. Okay, so before going to this, I want to show the working demo part of it. So let me stop presenting this and start presenting my command line. Okay, so I hope everyone can see the screen. Let me freeze the font a bit. Okay, so I hope the font is clear enough. Let me log into the device. Okay, let me check the version of Ansible that I'm currently using. Okay, so this is the environment is now set up for Ansible. Let me set that. So this basically sets up your Ansible environment. You can see the version now. So the current version that I'll be using is Ansible 2.11.2. So I have my demo content under my demo folder. And the first one that I'll show is Docker Bench for security. So let me go through the Docker Bench playbook. Okay, so as you can see, this is the Docker Bench security playbook. And what I'm trying to do is first I'm running on the local host and trying to elevate the privilege to urban level and trying to gather paths. And at this point, the task that I'm trying to perform is making sure that it is installed. And then I'm trying to download the Docker Bench security from the GitHub report to a destination to a local destination folder. And then I'm trying to run the Docker Bench security scan from the directory. And then I'm downloading the report locally and trying to report that result. So let me run this. Okay, so as you see, it gathered facts. It actually checked for git installation. Its access is already present. It will not show any change. And the Docker Bench for security also is already downloaded. It will not change as it will not show as change. So the first I will try to run the Docker command scan, the security command. And because of that, it is showing change as true. And then I just try to download it, try to download the report locally. And then it can be shown that, okay, at this part, my reports has been downloaded. So let me show you guys the report. Okay, so this is how your Docker Bench security result might look like. And you can see the first one is check result and it is checking based on host configuration. So these are the host configuration. And these are the results you can see, right? Warning info, warning info. And let's say if there is, let's see if there is any pass. Yeah, okay, you can see that there is one pass. And okay, sorry. This is for Docker demon configuration. And then for Docker configuration files. So likewise, it will go ahead and scan for all the parameters that it supposed to scan like container on time, Docker security operation, and Docker song configuration. And other files like, so this again started for Docker demon configuration. And another tool that I wanted to run with respect to continue security was aqua sectory. So let me just open the trivia. So this is very basic playbook. As you can see, I'm currently trying up. So first off, I have installed review. And then I'm the task that I'm including is verify image using trivia command. So I can use to be directly with the image. And here I'm using goal and version one, two, you'll find. And I'm trying to save the result in decent format. And then I'm trying to pass that decent file and trying to display the result. So if you can, now if I have the playbook should give the output in order, ma'am, to run the image scan. Okay, so as you can see, it ran the scan over goal find version one, two or one, one, two. And these are the volume that is currently found in this. So you can see the severity, right, critical severity as high, high. So based on your company requirement or your organization requirement, basically, we can choose to fix the issues that is being identified by trivia standard. So we can choose to identify critical, all critical issues and try to resolve first based on the priority we can decide on fixing high or medium or low priorities as well. You can see it has actually showed you all the results. They starting from high, medium, and low as well. So this was the demo that I wanted to show you all. So let's get back to our presentation and start presenting my slide deck. Okay, so hope everyone can see the slide deck again. So now this one is the most important part of our discussion, which is call for action. So basically, as we know, containers are rapidly changing the world of developers and operation teams and everyone wants to make it as a part of the DevSecOps pipeline. And it actually is accelerating in the world where security automation gets you to play a front role, front and your center role. So how you guys from the community can help us in achieving that particular security hardening and helps in achieving Ansible as a tool, preferred tool for container security. You can help us in identifying where you basically see Ansible as a benefit in container security world. Like you have a use case where you see that, okay, with this particular use case, Ansible can actually help in automating this particular use case and this can the entire use case can be automated and can be made part of CI pipeline or DevSecOps pipeline. So we ourselves are trying to come up with the integration with all the providers or the security vendors which are actually working in this case, container security and Kubernetes space. Well, out of those are StackRocks, AcroSecurity, Anchor, Prisma, Client, Vistlock, New Vectors and more. So Ansible would love to partner with container security vendor if there's an automation opportunity. So the first many of you might already know that Red Hat has, now StackRocks is part of basically Red Hat. So we are trying to come up with the first integration with StackRocks. So you can stay tuned for getting the integration news and with this particular integration, we'll have a dedicated module for StackRocks and with those modules, it will have all the documentation and everything like Ansible module has. So you can use those module, ready made modules and you can automate the entire scenario of what StackRocks exposes. So also as I told you, you can help us in coming up with the use cases and the things that you want to automate basically using Ansible. So to get in touch with us, you can join the IRC liberal channel which is hashtag Ansible Security and you can also ping us on Ansible network as well. And we have an Ansible Security e-book which is available and all of the demo source resources that I have just shown, all those contents are available and Ansible Security demo content, it has other contents as well. And if you want to check it out, you can go ahead and play around with it and let us know what are your thoughts. So okay, so this brings to the end of our discussion and if you have at any point here, if you have any question or queries with regards to what I presented just now, you can ask now. Thank you again for joining this discussion.