Hello everyone. Welcome to Con 42 DevSecOps 2024 event. Today I am presenting you one of the exciting topic about securing the Kubernetes ecosystem, a comprehensive multi level framework. Here is the agenda. I will cover key points of securing Kubernetes ecosystem, including about me, a statistical report from Red Hat, With allowing security facts. I will cover the goal of this presentation with a multi level security approach and architecture followed by a final touch. Let's begin. My name is Thyagarajan Aramudan. I am a cloud services manager with extensive experience in Kubernetes security. You can connect with me in LinkedIn. The recent Kubernetes security statistics report from Red Hat alarming trends. If you notice, about 67 percent of organizations delayed their deployment due to Kubernetes security concerns and about 46 percentage of organization lost their revenue due to Kubernetes security incident. Wait, no need to be panic. Let's stay alert. Our goal is to provide a multi level approach to secure the Kubernetes ecosystem. ensuring robust security at every level. We will explore multi levels of security. It is like an onion layers, applying security at each level. So let's say level one with infrastructure and then level two at cluster and then applying security at container level, applying security on the application layer and finally followed by applying security at code level. This architecture diagram shows a typical API and web application highlighting the areas that are not fully secured. Here, traffic from UI, front end goes to API management and the service A and service B deployed to Kubernetes. If you notice, the service A communicates to database and service bus, whereas service B communicates to all the systems like database, service bus, key vault and external services. And the service A also communicates to service B. In this architecture. The request from UI goes directly to API management with no controls. Here, no RBAC applied, no pod security as well. Pod have absolutely no controls. So it can communicate to any system by default. So system is at very high security risk. So let's start our multi level security approach and see how our clean slate with fully secured architecture going to be look at. Let's dive in level one infrastructure level security laying and securing the foundation. So securing the infrastructure layer involves implementing firewalls Applying the security patches and leverage cloud provided security features like Azure security features in azure Whereas in amazon, they have aws security groups and network acls I come up with a matrix table with security tool options for cloud and open source in case of azure We have azure security center nsgs and firewall which can be You Utilized for AWS they have security hub security groups and WAF which can be utilized And then for the open source, we can have firewall and OS ordaining, which can be used for applying the infrastructure level security. In this architecture, I have added firewall just before the API management and added the subnets and NSGs to protect all the incoming requests. This would safeguard the request. Securing the infrastructure is only 20 percentage of the overall security, but it is a critical foundation. Next level is cluster level security, protecting our Kubernetes core. We need to implement RAC and then enforcing a network policies like Calico, and then adding the encryption and the con in the communication layer where we can use the STO as a tool for encrypting the communication. So in case of Azure, we can have Azure R back and Azure policy. We can apply for the cluster level security for AWS. They have an a m roles and security hub. Whereas in open source we have the tools like calico and istio So in azure, aks, it comes with an add on an istio add on which can be utilized And calico also can be added to an azure aks so that the cluster level security can be enhanced. In this architecture, I have added Calico STO, which comes with Sidecar. Calico controls the power communication. The first step is to set global policy as default, deny all, to block all the incoming traffic. Then add network policy to enable the pod communication to corresponding services. Next, the STO encrypts the communication. Here, pod communications are managed, controlled, and encrypted. securing the cluster brings the security level up. to 40 percent showing the significant progress. Next is the level 3. Using, sorry, next is the level 3 which is container level security. Using the minimal base image and scanning for vulnerabilities are essential for securing the container images and runtime. In case of Azure we have AZR and AKS vulnerability scanning. And then for AWS, they have ECR and Inspector. For the open source, we have the image scanning tools such as Trivia, sorry, Trivi and Clare, along with the security contacts which can be utilized for the container level security. In this architecture, I have added scanning tool, real time monitoring tools, and signed images. This would very well safeguard the container. All right. Securing the container level increases the security to 60 percent demonstrating the importance of this layer. Next is level 4, which is application level security. In this layer, we need to focus on implementing secure coding practice and manage the secrets properly. In case of Azure, they have Azure Key Vault. AWS, they have Secrets Manager and IAM roles. And for the open source, there are tools like Vault and Sealed Secrets. And then we can also have secure coding practices applied at the code, at the IAM. application level. In this architecture I have added code repo and showing secrets stored in keyword. Securing the application level increases security to 80 percentage Showing substantial progress. This is the final level which is code level security. We need to conduct thorough code reviews, utilize the static and dynamic analysis tool and implement the policies for automated compliance check. In case of Azure, we have security features, DevOps security features and static code analysis tool and AWS as code pipeline security. And static code analysis tool and followed by in an open source. We have an open source sonar cube versions and opa so we also have the sonar cube, Licensed version which can be utilized in case of having More features comes with the SonarQube licensed version. So in this architecture, I have added DevOps pipeline, code reviews, policy enforcement, and code scanning tool. So securing the code, sorry, so securing the code level achieves 100 percent of security, 100 percent of the security, completing our multi level, approach. This is the ultimate secured architecture. So we can choose the tool based on cloud provider or any open source. The goal here is to apply the security at every level. We can use any tools like an observability tools like Grafana or any tools for real time monitoring of Kubernetes. vulnerability alerts. If you notice here, starting from infrastructure level to code level, Our code, our application is secured in all the levels. So this shows the 100 percent of secured applications. We can also leverage AOPS for proactive threat detection and self healing process. One more last thing is zero trust security model. it is a principle to follow, never trust, but always verify. One example is to apply it for granular access control. Here is the a hundred percentage secure protect, secure protected product introduced to buy multi-level of security. You can see, the secure product within the multi-layers of. multilayers of security conclusion. So securing the Kubernetes is not one size fits all solution. I'm going to repeat, securing Kubernetes is not a one size fits all solution. It requires a multi tiered approach that addresses security at every level. from infrastructure to code. With that, I complete my presentation. Once again, thank you all for listening and let's maintain our application safe. Thank you.