 Hi everyone, thank you for being here. I will talk about security in containers and Kubernetes. Let's continue. Let's see. In these presentations, I will give an overview about security from the source code and until Kubernetes. Talk about spline chains, container security and Kubernetes security. Here an overview about container and some tools and controls that we could use in security. When you build your image and next you will deploy it in some virtual machine or Kubernetes cluster, you will follow this step. We can see here the steps and also using CI CD, you could automatize some controls. For example, when we maybe you are more common with static analysis that you can introduce SAS, DAST, try to find secrets. But right now we are also using image data for cloud formation and you need also other tools like infrastructure scanning and also tools for vulnerabilities and misconfigurations. Maybe it's new for you the part of spline chains that it's a new control that it's important for avoid spline chain attacks. And you will need to protect your code, maybe create a spawn that is details of all your libraries and dependencies that you are using. It will help you with the source integrity, trying to search for the best practice when you are using source code management for example. Also the spline chains will help you with build integrity and deploy integrity. But also we will have the runtime protections that is in another stage because even if you have static analysis and spline chain, you will need also some tools or some controls to avoid you having an attack when your container is already in production or run. And I think here especially I will put some attentions about EBPF because I think one of the main differences between traditional applications and cloud native, maybe when we talk about traditional, we will try to search for capturing package. We have some other traditional security tools that they try to do some foreseeing about all the package or the network that you can identify. But this kind of approach in containers, it's more difficult because try to capture package, it's very expensive and also ineffective. And it's that that EBPF programs could help you to collect events in real time without disruption of your applications. So this is like a new approach for cloud native and security in this approach of networking and security. Supply chain is an important topic. We can see here we have three main streams, source and build and deployment integrity. The main focus is because we have so many attacks in supply chain attack. You can see from solar winds and also so many problems with the dependencies about how we build our product. For example, it depends on function that basically anyone can alter some package in some upstream level and everyone is affected. So that is the main problem. With supply chains best practice, you can try to resolve this. For example, with a spawn that maybe you already hear, we try to receive a list of all the package together with all the dependencies that contains your artifactory that could be your container image or your code. And this is the main step to try to validate the integrity of your source code. Here also, I will continue. Here we have a security guide for supplying chains. The Center for Internet Security create a benchmark. With chain bench, you can automatize these controls. These controls is basically applying about these three main artifacts that will be the source, the build and the deployment, try to validate integrity. For example, prevent a malicious code that it can commit in your repository or sign it, your artifacts in the build process, for example, when you are creating an image. And also in the deployment, you only have to deploy sign it artifacts. You can validate with all these guides, will validate all these steps between all these flow. And also we have salsa that it's also another framework for supply chains, supply chain levels for software artifacts. And you can use this with this tool, you can have these both outputs, these controls, you can validate if you are following this best practice about supply chain. Container signing is important part of supply chains. You can use a tool like cosine or notary to sign the artifacts. In the case of image, you sign your artifact that is the image. And when you will deploy to Kubernetes, for example, you validate, verify that the source that you are pulling this image is a trusted source. Also, using admissions controller, you can validate, you can automatize inside of Kubernetes these steps. The general steps as you can see in the graphic is about signing is to generate a key pair to sign your image container or any other artifact. And when you will use in the deployment or in your infrastructure this artifact, you validate that this artifact is signed. Also could be other artifacts, could be like hand charts or web assembly models or even EVPF programs. You can validate these artifacts before you deploy it in your infrastructure that is from a trusted source. So this is important steps in the supply chains. Well, let's talk about more container security and right now we are seeing the top thing about OWASPY. That is the top thing of the main problems of vulnerabilities or misconfigurations in web applications. And as you can see in this step, you already can solve this, resolve it using SAS and DAAS tool and also supplying using the best practice of supply chains. You need to do this kind of steps before and when you already validate these issues, you also can focus in the container security because you can do the best practice that we will talk about container. But if you don't review this before a stage about your web applications with these no issues, your container also will be exposed because inside of your container is this web application that is not following the recommendations about web applications. Okay, so let's talk about more about one of the main issues that you have to put in your pipeline that is review misconfigurations when you build your image. And one of the basic problems about misconfigurations is that you have to avoid to use the rootless, to use the root user. Avoid to use because this could have issues that someone that can break inside of your container. It will be very easy to get access to the host. So you could avoid this trying to create a user also try to drop capabilities. And another important about container security is validate for your vulnerabilities because as your source code can have vulnerabilities that is validated maybe by SAS DAAS tools. You also need to validate the vulnerabilities that contain your image with the small image you have less vulnerabilities that is a good practice that you try to build a small image. This will reduce your attack surface and right now I think try to avoid to use a root user and I have a checklist for more deeper details about like protect also your container runtime. Try to protect your host. Yeah, this kind of details also is part of all the cycle of your container. For example, if you are only using Docker, you need to follow the best practice with the Docker container runtime. And yeah, I think these two main parts about review your misconfigurations and the vulnerabilities are very important, at least the minimal things to review in your container security. Let's talk about more current security in the next slide. In Kubernetes infrastructure, we have to take care about the main components that it will be the master and the nodes. Try to limit the access to the Kubernetes API server. Try to see what are our trusted networks to allow it to access also try to think about how is the architecture and the communication between the components. For example, here you can see the parts that you need from the perspective of the master and the node. Also the other components that are important, for example, it is the task that component is encrypted. You are using TLS communications between these components for the communications. And if you think about also in the host security, you can try to validate that your host, maybe your Ubuntu, if these installations are following the best practice, for example, the sys benchmark, or they are following some compliance from the point of view of the operator system. Next, we can use the own Kubernetes features to improve security. In authorization, we have AirBug, a role-based access control, to help us to reduce the permissions to apply the least privileged access. We could reduce permissions, authorize only that our applications needs to access. And also we have components like authentications that could help us to know who is inside of our cluster components, who really can get access. And if we use with single sign-on depends on how our organizations get access to the cluster, we could do these kinds of settings. And also we have the secrets part that you could try to use in cryptations and also try not to leave the secrets in your application. This is maybe if you can use a leader, you can not expose that inside of your applications. And one special component is the pod security policy that right now is replacing with pod security admissions that help us to apply the best practice in container security, like not to use a root user or remove capabilities. And all the good practice that we see in container security, we call applied with security admissions, with this security control for the pod. And another important component is network policy that will help us with the segmentation. We could use this component to create layers between our applications to create more walls to defense against attacks and also to be more isolated between the context that we are creating our applications. And the network policy will help with us. And also we have components in size of Kubernetes like enable the auditing APR server. And you also, we always can improve this, the part of observability using some logging for get the logs inside of Kubernetes. 60% of the breaches, it's because of misconfigurations. And this is a step that you can do in your pipeline introducing your CICD. You can use a tool for searching with these misconfigurations and avoid to be part of the report. Talking about networking, especially networking in Kubernetes and cloud native. We can imagine people that is used to work with traditional applications. They use a lot the package capture. But if you think about use this technique in containers, it's really difficult to find people that has successful use this technique because the container is rebooting. It's ephemeral. And he is continuous changes. And if we try to use this kind of technique, we overload our container and we don't get some successful results. It's that going techniques, new techniques like or new applications because CBPF is like 10 yards old. But right now we have new applications using CBPF that help us in this kind of approach in networking and security. Well, attacks against Kubernetes. We are doing this checklist from containers until Kubernetes because we want to prevent attack. And one of the main common attacks that we can find in Kubernetes is because misconfigurations in authorizations, for example, is an airbag problem. We give too much access and we need to improve this part. I know that this part of airbag sometimes is very difficult because it's complex inside Kubernetes when you try to apply the service accounts and roles and reduce the access to the resource inside the API. But definitely we have more tools to help us with this overview about security in airbag. And we also have, when we talk about security, the zero days that is new vulnerabilities that is always appearing. It's always happening. So we need to be prepared. We need to have some runtime tool to help us to mitigate when our container is already running in production. And we have several kinds of attacks like river shells. We can have lateral moving. The problem is always, it's always happening. Or attacks more advanced like fileless malware. Fileless, it's very difficult to detect because the malware is not running in a file system. It's running in memory. And with this technique, it's more difficult that traditional security tools try to find or discovering this kind of attacks. Here we have an overview about Kubernetes security. And one of the first components is the code. Could be any language that we are building our applications. We could use tools like SAS, DAAS, SCA to look for vulnerabilities, for vulnerabilities in the dependencies, also looking for secrets. And this is like at the first stage. And when we build applications inside of image, we also, in this new artifact, new component, we also need to find vulnerabilities because we know that we have other components that how we are building our image. For example, which, from which base, it could be like from Wuntu or from a T-Rollet. But we need to find again, again, vulnerabilities, also misconfigurations in the Docker file. Or find also if when we build this image, we have some hard codes to do some secret scanings. And when we go to the other level that will, that it will deploy this image inside of the cluster. We also have best practice. Maybe you know this Kubernetes security posture managing that is a resume about the controls or best practice that you need to do against all the components of Kubernetes. Like for example, look for specific vulnerabilities of the Kubernetes components or also misconfigurations in the Kubernetes components. Or even in the manifest of the Kubernetes or how you can find misconfigurations and you have tools to help us with that. And when you think about the other component that is the cloud, you also can look for misconfigurations when you create this, the service. For example, if you use some EKS, if this is exposed to the internet or how all this information is connected or even for any of these components, you could get, you could receive an attack. It's important that you can have control in each stage. So I am, yeah, I think security is very complex. And I am putting some resume in this repository if you, if you want to give, if you want to see with more detail. And just finally, thank you so much for being here. I leave my contacts and please contact me for any doubt or any feedback. I am leaving my repositories that I am trying to do some checklists about everything that we talk about. And well, see you. Thank you.