 And the next session is going to be Kubernetes security and governance made easy using Otomi. And this is being hosted by two of our friends here, Abhimanyu and Ehozafa Zivnovoda. So I'll give a brief introduction about Abhimanyu. Abhimanyu Selvon is the developer advocate at RedCubes. He's a software generalist who has worked in industries such as aerospace, robotics, e-health and is landed in the cloud native realm. His focus lies in the intersection of maximizing the developer productivity and enhancing business values. He's an open source enthusiast and is currently leading the developer experience program of the Otomi core project. Outside of work, he enjoys enduring, endurance running and cycling. Thanks Abhimanyu to be part of this program. Thank you a lot. Ehozafa Zivnovoda is an engineering manager at RedCubes. He aims to empower DevOps teams by listening to them and providing the autonomous environment that they need. He's specialized in building software for different engineering teams from system platforms for telecom equipment to pass on top of Kubernetes. He has a strong computer network background which helps him design interconnected and distributed systems. Currently he's a maintainer of the Otomi core project. Great team player who loves working with others. After working hours, you can find him hiking in the mountains or biking on the road. Cool, that's a great introduction, isn't it? Okay, about this session. Thanks, Ehozafa, thanks for being with us. And about the session, Otomi is an open source cloud agnostic Kubernetes application configuration and automation platform. Under the hood, Otomi leverages several OSS and CNCF projects like Calico, OPA gatekeeper, Istio, hardware to enhance security. Security is an ever-growing concern for organizations. Gartner predicts that 99% of all security incidents by 2025 will be due to misconfigurations. This talk will demonstrate how teams can use Otomi to manage container and network security policies with same defaults on Kubernetes through an intuitive web interface. Thereby avoiding the need to write any YAML configurations that are prone to errors. A recorded video demo is used to showcase a couple of use cases using the integrated security best practices in Otomi to reduce the attack surfacing surface when running applications on Kubernetes. Cool, so the session will start in a couple of minutes and thanks Ehozafa and Abhimanyu for being around and we are all excited to go through the session. Yeah, it'll go in a couple of minutes, thanks. On Kubernetes security and governance made easy using Otomi. This talk will demonstrate how teams can use Otomi, our open source project to enforce container and network security policies with same defaults on the cluster through an intuitive web interface. Thereby avoiding the need to write YAML configurations that are prone to errors. We will also see how leveraging automation and GitOps can mitigate the misconfiguration errors. Hi, I'm Abhimanyu Selvan, you can call me Abhi. I'm the developer advocate at RedCubes. I'm a software generalist exploring the cloud native realm and my interest lies in improving the developer experience and productivity. Hi, my name is Ehozafa Zimnovodda and you can call me Eho. I'm the engineering manager at RedCubes and together with my colleagues we are maintaining the Otomi core project. Here is the agenda for the talk. We'll give you a general introduction about our open source project at Otomi and then go hands-on demo demonstrating container security policies, egress control using Istio, network policies and then key takeaways from this talk. Finally, how y'all can contribute to our open source project and community? Otomi is a self-hosted platform as a service for Kubernetes that aims to lower the burden on operation and make developers self-serving. It is an open source project that can be installed on any Kubernetes cluster. Otomi integrates more than 20 open source projects and brings multi-tenant experience so each DevOps team has its own self-sufficient environment to work with. We can enforce container security policies and network policies in Otomi without having the need to write any YAML configurations, everything through a single intuitive web user interface. Otomi can be easily installed using HelmChart but for the sake of this demo we'll only focus on the security and the network policy enforcement aspect of Otomi. Welcome to the demo on container security policies. This demo will demonstrate how easy it is to gain access to the host file system by deploying a ROG pod and we will also showcase how simple it is as a platform admin to prevent such an attack from happening by enabling the security policies via the Otomi console without the need to write any YAML configurations. So let's go ahead and deploy this ROG pod that has privileged container running with hostpad volume mounted and the host security flag set to true. You can note that I can easily gain access to the host file system and the possibilities to create Havoc's endless. We can easily prevent something like this from happening by enabling the pod security policies from the Otomi console. Let's check it out. Now we've logged into the Otomi console as a team admin. We will now enable the settings for the team KCD Chennai. What you see in the bottom is the list of core applications that Otomi comes pre-configured with by default and the applications on top can be easily enabled by dragging and dropping them. In this case, we want to enable the policies. So let's go ahead and enable OPA gatekeeper to enforce these policies and let's see what happens. Now see that gatekeeper is part of the enabled tabs. We need to deploy these changes but before we do so, let's enable some settings of gatekeeper via the console. The Otomi console provides high level abstraction of these pod security policies that can be easily enabled from the console. Otomi comes pre-configured with projects such as kitty and drone to enable automation. When you fill the form and click deploy changes, Otomi automatically generates the configuration as code, commits the changes to a pre-configured Otomi values git repository which triggers a drone pipeline that will validate the changes and apply the changes to the cluster automatically. So let's head back to the terminal and see if we are able to deploy the robot. We can see that the admission controller has denied the request to create the pod with the non-compliant configuration. This confirms the fact that the pod security policies have taken effect. Otomi has just shown the importance of having container security policies which can limit a vast majority of attacks. The next level of enhancing security is by controlling the network traffic which may play a key role in highly distributed and interconnected environments like pods in Kubernetes cluster. In this demo, I will talk about controlling network traffic from a pod to the internet network. A very common attack is so-called remote command execution which allows an adversary to run an arbitrary shell command. It often results in leveraging a curl command, fetching malicious software and executing it in memory. Since package manager is available, the attacker installs the curl binary which mimics downloading a malicious software to the pod. Then HTTP request is performed to the endpoint outside the cluster. Let's head back to the Otomi console and prevent any traffic going outside the cluster. I'm going to update the team settings of KCD-GNI and enable egress control feature. We are back to the terminal. As a result of enabling egress policy in Otomi console, the default Istio sidecar resource has been deployed by Otomi. I try again downloading an application from the internet. It's not possible anymore because Istio blocks traffic going outside this service mesh. We are going to inspect the sidecar configuration. So there is a default sidecar configuration deployed for a team KCD-GNI. Otomi enforces external egress control by setting outbound traffic policy to registry only for this particular team which means that the pod cannot access any endpoint outside the service mesh. Yeho just talked about controlling the external egress traffic but what about the interpod communication? For the sake of this demo, we will deploy a guestbook application that consists of three microservices, the frontend, the Redis leader and the Redis follower in the team KCD-GNI namespace. We will also deploy a snooper pod that will be able to communicate with the Redis service. This demo will be split into three parts as shown in the figure. First, we will allow all the traffic to flow through so the services will be talking to one another. The snooper pod will also be able to ping the Redis leader. Then we will log into the Otomi console and enable the network policies which by default will deny all the incoming traffic. And finally, we selectively allow the traffic to flow through the microservices by white listing the applications on the Otomi console. In the terminal, we deploy guestbook application which consists of three Kubernetes services. In the Otomi console, we have already exposed the frontend service with the public URL that we are going to access now. This is the guestbook application and we will leave few entries. By submitting them, the frontend connects with Redis service where the data is stored. Let's get back to the terminal. I'm going to deploy a snooper pod which sends a ping message to the Redis leader service. Communication is allowed because no network policy is enforced. As you can see in the terminal on the bottom right corner. We move to the second scenario where the default network policy blocks all incoming traffic to the pod in the team name space. I just visit Otomi console and enable the network policy feature by editing team KCD Chennai settings. After enabling network policies, the frontend service is not able to communicate with the Redis service anymore. We head back to the terminal where we inspect Kubernetes resources that Otomi has deployed for us. There are two network policies. The first one blocks all incoming traffic to any pod in the team KCD Chennai namespace. The second one allows control plane traffic from core services like Prometheus, Istio or Knative. One more time, I deploy the snooper pod and check if it can communicate with the Redis leader service. The deny all network policy prevents snooper pod communication, but I need to allow incoming traffic from the frontend to the Redis service. In Otomi console, I'm going to register two more services so I can enable network policies for their pods. Next, we define the network policies also for the Redis follower. Again, we want that the frontend service is able to communicate with the Redis follower. We are back at the guestbook application. Now it's possible to add more entries. The communication has been restored. Let's check network policies that Otomi has created after registering new services. There are two new resources that target Redis pods and selectively allow incoming traffic. With this, we have concluded demo about network policies. Kubernetes is complex. Implementing security across dynamic environments of organization takes a toll on the engineers. Enabling a security-driven mindset to build secure applications is paramount in today's world. As open source enthusiasts and contributors, we have built Otomi by honoring several open source projects and integrating them into one platform. Otomi was built ground up from a developer's point of view where we have abstracted away the complexity of implementing security across the platform by providing high-level security principles that are easily consumable. This approach not only enables organizations to build fast, secure environments, but also enables team and engineers within the organization to develop a secure mindset from the inception of the application-building process. The most important part of this talk is the open-source community. As mentioned earlier, Otomi is 100% open source. So feel free to check out our repository, RedCube slash Otomi Core, and do give us a star if you enjoy it. We also have quick start repositories to help you quickly install Otomi on your favorite cloud provider. We can also run Otomi on Minicube. We also have some workshops, repository where you can try out different labs and experience the true potential of Otomi. For docs, you can visit otomi.io. And to join the community or Slack channel, you can visit redcubes.com slash community and subscribe to our events in Slack channel from there. We look forward to hearing back from you all. Thank you very much.