If you’ve heard about Jenkins, but you are not really familiar with the way it functions, this video demo will help you get a clearer picture, both on the theoretical and practical aspects of this very useful tool.
[Video Transcript]
What we're going to discuss, at least in this demo, and what I'm going to show you, it's how we can perform or extract or find vulnerabilities inside our application. Right?
In this case, we will assume that we have the application packaged in a Docker container, maybe that application has some vulnerabilities inside it from the point of view of the libraries the binary's used, and what we try to accomplish?
We have the code, we have to build the image, we have to scan the image and if this code passes, we push the image to Docker hub. Let's say, if we find vulnerabilities, we will fail the build, and we will not move on.
We are not going to do the entire end to end, continuous integration, continuous delivery pipeline, we are going to do just this small part, so we can think of the following. Downloading the code from the SCM, building the container image, scanning that image, publishing the results, and based on the pass or fail criteria, push it to a Docker registry, in this case will be Docker hub. Right? So. Let's take a look and see what we can do here.
What you will need, if you want at least to deploy or use, or create this kind of pipeline you will need, of course, or the following are Jenkins server up and running. You will need an application, of course, in my case, it's somewhere on GitHub. You will need also, or enter, enter it's another tool and the purpose of this tool, it's to find vulnerabilities inside of our applications, which are packaged as Docker containers.
And, of course, you will need an account on GitHub. I already have it here. So, the pipeline it's already created and contains the following. Let's stay, stages. We have the cloning of the code who has the building image. Okay? We perform the container security scan. We deployed the image to Docker hub and we have a cleanup phase. So we have one, two, three, four, five, five stages. Of course, in each stage we have a series of steps or more or less.
How this can be done as you can see here, my job is created as a pipeline script. And if you are looking at this, basically this is some kind of code, right? So, what we can do more on top of this, we can try to automate automation of the Junkies jobs, because if we want to add more steps, we can put these in, on GitHub repo, and we can create new stages or new steps.
And on the commit, you can create a new build, which will run these pipelines, and things can move on in order to create that end to end workflow. So, let's take a high level overview of this. As you can see here, I have defined a pipeline with some specific variables, which are related to this pipeline. We have a registry, like I said, this is the Docker registry in my case, it's on my account on enter. And as you can see, I have images here, Docker image it's none, agent any, this means that this pipeline can be deployed on any agent. In this case, I don't have any agent. So an agent can be a virtual machine, which has, or a Docker container or a Kubernetes pod or something else, but the requirement is to have a Jenkins agent, which is running on, on top of it.
Why is that? Maybe you have specific applications that need specific environments, right. And those specific environments maybe, or you want to use and integrate them in this continuous delivery and continuous integration workflow.
If you have this kind of requirement, you have to just specify here, agent and you specify the name. Right? So. Let's see what is the first stage, right? It's cloning from Get. So, as you can see here, we are using another tool Get, which also has to be installed on the Jenkins machine and here it's downloading our code. Right?
If I'm going to this location, as you can see, I have a Docker ignore and a Docker file. And this Docker file contains these different steps and contains another image, and this image has some vulnerabilities inside it. Right? And we wanted to find these vulnerabilities. And try to fix them and try and again, the scan and try to improve that.
This is the main idea, right? So we download our code from the Get, and the first step, remember I have a Docker file, for those who are familiar with Docker fire the first thing that we need to do is to create the Docker image, right? Because containers are, the application will be created from that container image. Remember, containers are ephemeral.
The next step after we cloned from the SEM, it's to create this image, right? And here we are using some specific comments and we are performing a Docker build, using some specific flex in this case. It's built now after that, we are going on to the next stage and are performing the security scans. Right? So, here, for this step, I have the enterprise again, which is integrated with Jenkins and basically this line enter, and so on and so forth with these parameters, we'll perform, uh, we'll perform the scan, I will put this to false because I want the build to be successful. If it's true, it will fail.
And let's say we execute these enter parts. So we perform the scanning with this tool. This tool, by the way, it's also deployed in a Docker. So it will scan the image on a Docker environment and it will find vulnerabilities. It will report those vulnerabilities and based on the report, it will move to the next step or not.
In this case, the next stage will be deploying the image to the Docker hub. As you can see here, we have Docker image push, and lastly, we can have some kind of cleanup with specific share scenes.
This is the pipeline, let's apply this, and let's see if we can run it. So the last bill 19 was failed. As you can see it failed the security scan. Let's build now and see what happens behind the scenes. Remember that view or discussion for the steps for the stages, as you can see, these are the stages, the name of the stages for official presentation. It will help us to see more clearly what is going on inside our CI CD pipeline. So, if I'm clicking on this consult, I will see that the code is downloaded from Get.
We are performing the Docker build as you can see, you have different Docker outputs here with all the steps from the Docker file after that we started the enter, and if you are taking a look at this, we can see that we can see that on worker took this job and started the scanning process. Right?
And going from further, we can see this request was accepted and we are waiting for specific outputs. And as you can see, this is an automatic loop, which is telling us that the image it's analyzing, and we are waiting. It will take another one of two minutes.
Now it's an analyzing state, and at the end of the scanning, because I enabled that variable failed on the band, it will move to the next stage, even if it will find vulnerabilities.
And it will do this in this case for 5,000 retries and the retry it's done one second interval. Good. Let's wait a little bit more for that, and see how it goes.
Meanwhile, please feel free to ask questions because we are reaching the end of the webinar and I will be glad to respond to your questions.
The scanning was completed. Now it's logging to my Docker hub account and is pushing the image to that account. Right? And all of these steps are done inside the pipeline. So if I'm going to my Docker hub account on performance refresh here, I should see my bild.
I think the number it's 20. So should it be 20 here, with the tech 20, right?
And I consent to the cookies. Okay. As you can see, look 20 a minute ago, right? So it was a part of my Jenkins job. And as you can see, the pipeline ended with success, and it's green. You see each stage of the pipeline was a success. So you will ask me what is the difference between build 20 and build 19, as you can see in this case, it failed.
Why? Because I told the PI, I configured the JMP Jenkins pipeline to fail the build. If entered we'll find any vulnerabilities inside of the Docker container. So, let's look and see what vulnerabilities we have here. So, we have this enter report, and as you can see on the latest image of Andrea, we have a different, common vulnerability. One of our abilities and with different problems on the OAS package, on DPD, on the DP kg, high. High vulnerability on the one, two, and so on and so forth. So we have many, and here we have the gate action stop. Basically, if we, the engine, the enter engine is configured to fail the build, if it's found high severity CSVs. Right?
I know this is a demo environment and it's an older application with some old CSVs, but if you have code that he uses a lot of libraries or modules, and those modules change often because you are performing different updates and so on and so forth, you will need some kind of analysts engine in order to validate your Docker images. Right? Of course, if you have sensitive and important data here.
As you can see, we have many CSV found in this. So basically this should fail. This should not be, this should not be deployed to production.
share this on:
