Hi, my name is Amar and today I will talk about the modern infrastructure security that is zero trust container security. We will dive into how it works, why it's needed, and practical steps you can take to implement it. But before we get started, I would like to talk about a little bit about our, company and, myself. We are Oxygen Security based in Maryland and we have been around since 2018 and we have been able to help over 50 different customers to build out their digital transformation journey from on prem to hybrid to multi cloud. We have been able to help them integrate DevOps including, test and interactive testing and security validations of the networks. I am a cloud and DevOps engineer working across major cloud platforms like AWS, Azure and GCP. I specialize in crowd security assessments, cost optimization, and microservices orchestration with a focus on automating DevSecOps process. Currently, I work as a senior DevOps engineer at Oxygen Security, where I design and implement secure, scalable cloud infrastructure and streamlined CI CD workflows. So what we'll be discussing today, we will explain how DevSecOps works. for containers, how to apply zero trust principles to containers, integrate it into development life cycle, and see the practical examples of how it works in real world scenarios. Let's dive into the zero trust. Zero trust is a strategic approach that eliminates implicit trust in your systems. in the traditional security model, we used to assume, we assume to, we assume that everything inside the corporate network could be trusted by default, but, this model is outdated given today's cyber security threats. Instead, zero trust is based on the principle that trust should ne should never be guaranteed by default. if you look at the second point, trust is neither binary nor permanent. This means trust is not something you give once and forget about. it must be continuously earned and verified, which is the essence of the zero trust. Now you may ask where we can apply the zero trust. the answer is almost anywhere. It's applicable to nearly all organizational functions, from securing cloud workloads to container environments, and even endpoints like laptops and mobile devices. The Zero Trust process can be broken down into four steps. Establish trust by enforcing authentication and authorization mechanism. Enforce security policies across your environment. Continuously verify, continuously verify by, by the constantly checking if trust should still be maintained. Respond to threats in real time using automated incident response mechanism. Zero trust, in, container security means that we don't automatically trust any part of the system, whether inside or outside the network. Everything must be continuously verified to ensure the security containers face several challenges just like underlying host system which means if the system is compromised the containers are at risk. Another issue is securing the container registry as the images used to create containers may have vulnerabilities. Additionally containers can be attacked while running if they are not well protected. it. And using third party container images could introduce security flaws. This is why security zero trust is crucial for containers. It allow for, fine grained access control, ensuring that, the authorized users. that only, the authorized users, only, only the authorized users, authorized users or the systems, can access the, containers. It also enforces the principles of least privileges, least privileges, it means, It means that enforces the principles of lease privileges, meaning that, the containers are given only the permission they have needed, zero trust prevents attackers from moving between containers, monitoring activities in real time, and helps with security standards like SOC 2 and GDPR. The process involves establishing trust, through authentication and. Forcing it by protecting data, regularly verifying container activities, and being ready to respond to any threats in let's move to the new slide. in this, today's world, everything is everywhere. We are no longer in an era where we are applications or services are neatly contained within a single data center. Modern architectures are distributed. We have microservices, cloud native applications, and geographically distributed deployments. All of these factors add complexity and increase the, and increase the attack surface, making security more challenging. Additionally, the workforce has changed. Remote teams are now the norms, and employees are working from home, offices, or even the coffee shops, all accessing networks from various devices, securing these diverse environments. becomes essential. Nowadays, nearly every application we use, whether for business or personal use, relies on the multiple internal and external integrations. These integrations connect different systems and if any one of these points is insecure, it can serve as a gateway for cyber attacks. We must consider the global supply chain, which includes open source, open source. Softwares and components that many organizations depends on. These can be a security risk because vulnerabilities in widely used open source libraries can affect the countless, application globally. As we discussed earlier, the zero trust process involves establishing and forcing continuously verifying. and responding to the trust. Here is the map each of these zero trust principles for container security to the respective stages of the process. Segmentation, this is about dividing your environment into smaller manageable zones. And it's quickly controlling the communication between them in containerized environment. Microsegmentation ensures that even if one part of the system is compromised, the attacker cannot easily move laterally to other, to the other containers. You control which containers can communicate with each other and restrict unnecessary traffic. The second is runtime security. This principle ensures that containers behave as expected once they are deployed. You monitor container activities in real time. Looking for any suspicious action such as unauthorized, or unusual network traffic. If a container tries to run a process, it was not intended. So we need to detect and block that, action immediately. The next is network security. This is the backbone of The any of the zero trust approach, we must secure the network communication between the containers, whether they are running on the same machine or across distributed environments. This includes implementing strong encryption and securing all communication channels, ensuring that traffic between services is trusted and authenticated. The fourth one is IEM. Here we strictly control who has access to which resource in a zero trust. Until every request for access must be verified, IAM ensures that users and services are only given the minimal level of access they need and access is revoked as soon as it's no longer needed. The fifth is image security. The foundation of any container, In the container image and securing these images is critical image security involves the scanning images for vulnerabilities before they are deployed, enforcing sign images and ensuring they have not been tampered in this slide, how we can discuss how we can, how we can implement zero trust container security. throughout the DevOps lifecycle and map the principles which each of the DevOps lifecycle stages. starting with the build phase, this is where, we focus on the vulnerability. We implement build scanning to detect any vulnerabilities early on in the development. And we also enforce security policies as code. This ensures that our security standards are embedded from the start. Next phase is test. We scan our container registries to check for vulnerabilities. This followed by security automation, which help to streamline our security checks and testing. We also implement admission controls to ensure that only trusted and secure components make it through. As we move to the staging phase, we focus on the compliance, which is CIS benchmark. are used to ensure we are meeting industry security standards. We introduce a container firewall at this stage, adding an extra layer of defense to protect our workloads. In the production phase, we continue to ensure compliance with frameworks such as PCI and NIST. Container's workload security is our priority, which includes protecting running applications from any threats. We have runtime protection. This is where runtime scannings and real time alerts are critical for detecting and responding to threats immediately. Immediately as they happen by applying the zero trust approach across the life cycle, from a build to production, we can ensure that continuous security protecting both our, microservices infrastructure and data. Let's move to the real world. here we can compare the before and after ZeroTrust security changes. Before ZeroTrust, we see that applications are deployed without consistently verifying container images leading to potential vulnerabilities. After implementing the Zero Trust, every application, regardless of version, undergoes image scanning to detect vulnerabilities and ensure trust before the deployment. This continuous verification process strengthens security by ensuring only trusted applications. Secure images are deployed using the risk of breaches in our, in our microservices environment. Verifying the image at, at, deployment time ensures that only trusted and verified images are used in our production environment. This process ensures that security is not just a one time task, but, continuous and ongoing activity, in your pipeline. The next, example is micro segmentation before zero trust. All containers within the application can communicate freely with each other, which increases the risk of, lateral movements during an attack. After implementing zero trust, micro segmentation containers are segmented into isolated groups, each with a specific security policies applied. This limits communication only to necessary components, reducing the risk, reducing the attack surface, and containing potential threats. With micro segmentation, we can apply fine grained security controls, ensuring each container is protected individually. This approach isolates the backend containers and only allow ingress traffic, from the, Name space selector, which is backend services by applying this strategy We limit the movement of attacks within the system reducing the attack surface and minimizing the risk before zero trust IAM containers have broader access which increases the security risk or unauthorized actions can occur across the environment After implementing Zero Trust, fine grained access control is enforced. Each container is granted the least privilege necessary to function. And access is tightly coupled, tightly, controlled based on the specific rules and policies. This ensures that only authenticated and authorized actions are permitted, minimizing the attack surface, and safeguarding sensitive resources within the microservices environment. In this harness pipeline, an IEM role can securely pull the container image from the AWS Elastic Container Registry, ensuring that only authorized users and process have access to critical resources. Before Zero Trust, all containers one, two, and three are, unsecure and vulnerable due to unprotected communication path. But after Zero Trust, container network security for every container benefits from consistently applies security policies and dinners are isolated and protected by secure network policies, reducing the risk of unauthorized access and natural movement. This comprehensive network security ensures a consistent, secure environment for all the containers. Here we enforce strict policies, continuously monitor traffic and respond to any anomalies by coding the mauth service as part of the service mesh in this, in this manifest file. We ensure that authentication is applied, at, broad namespace, helping to, helping to protect, our environment from. from the unauthorized access. Before Zero Trust, we use security policies to manually enforce the containers that are used it. And after Zero Trust, we enforce policies as code on every container to protect runtime container from security threats. if a shell is started as a root and alert will be sent to the, immediate action. This real time enforcement and the monitoring, ensures that we can respond to any security threats that, that arise, during the runtime, protecting the system while it's operational. thank you for joining me today for this conversation about, I hope you had enjoyed. this conversation. If you have any further questions or you would like to, have a questions, feedback, feel free to contact us on www.dot io and, on my email info at dot I, and han at io and I am always happy to respond your feedback. Thank you and have a great day.