 Cool. Welcome fellow Kubernetes enthusiasts. Thank you for joining the session today. Of course, we will be talking about the Kubernetes and securing numerous moving pieces in Kubernetes cluster in order to build a secure Kubernetes ecosystem. We will also be looking at an open-source tool named CubeStriker that I have been developing for the last few months. So let me start by introducing myself. My name is Vasant Chinipili. Like many of you I'm sure, I am an IT and security fanatic, and my experience spans across various domains of information security, such as like cloud security, container security, and penetration testing. I am currently working for a startup named MX 51 in Sydney, where I play the role of a security architect, a security engineer, penetration tester, and a compliance specialist. As you can tell, I wear multiple hats which certainly keeps me on my toes. Now let's, well, now that's the introduction is done, let's dive into more fascinating stuff, the world of Kubernetes. Getting started with Kubernetes is easy. It takes a matter of minutes to set up the new cluster and run applications. However, the real concern of the challenge is what follows this? The pivotal question of how to make sure your cluster is secure. In fact, let me tell you exactly what happens in the real world when Kubernetes clusters aren't secured properly. In mid-2019, second largest auto-finance company in the United States was hacked, and huge amounts of great data, social security numbers, and bank account numbers of more than 100 million customers was leaked. Do you recall who this was? It was Capital One. World's famous automaker was one of the earlier victims of crypto-jacking when a Kubernetes cluster was compromised due to an administrative console not being passable protected. Can you guess who this was? It's Tesla. There are many other instance like Microsoft's Kubeflow breach and talk-ahub last year where attackers managed to plant delicious images. Well, now that we have understood the dangers facing our industry and given the knowledge gap among the teams and the lack of solid security measures to protect Kubernetes, you might be wondering how in the world, are we ever going to secure all these moving pieces and stop these attacks? I have the same exact thought, and that's what led me to build a tool named KubeStriker. In simple terms, the object of KubeStriker is to secure the cloud native in the most efficient and user-friendly way. The cornerstone of security is visibility. You can't secure what you can't see. Therefore, KubeStriker adopts this philosophy and aims to enhance the visibility by acting as a security-orditing tool for Kubernetes. It is platform-agnostic tool incompatible with various platforms such as Salesforce for Kubernetes, Amazon EKS, Azure EKS, and Google GKE. It is specifically designed to tackle Kubernetes cluster security issues due to misconfigurations and will help strengthen the overall IT infrastructure of any organization. Now, let me show you exactly how the magic happens. You can install KubeStriker using Python or PIP in just a matter of seconds. In addition to that, you can also spin up the KubeStriker with just one command, and it can run anywhere regardless of the operating system as long as you have a container run time installed. Now, let me spin up quickly the KubeStriker container. There we go, and KubeStriker accepts three forms of inputs. Are you all on an IP address, or you can choose from your KubeConfig file, or you can provide a range of IP addresses which could be a combination of your master node and the worker nodes. For the first scenario, let's scan a cluster that is hosted in the Google Cloud, the GKE engine. Let me provide the IP address of the cluster, and KubeStriker gears up with a reconnaissance phase where it checks for a host of ports and various services such as live, KubeServerSecureService, InsecureService, KubeNet, ReadWrite, and ReadOnlyPorts, HCDPorts, and KubeProxyPorts, and any other ports that are open on the cluster. Once the services are identified, it lists all the different services that are identified during the reconnaissance phase. This snaguit has identified KubeServerSecureNPoint identified, and it also tells us the version of the Kubernetes that is running on the cluster. Then it gives us two options, whether we want to perform an authenticated scan or an unauthenticated scan. You can relate them as a black box and a white box system. In order to perform an authenticated scan, we need to provide the token so that the tool will assume the token and reach out to the Kubernetes cluster and enumerate all the misconfigured services. Because the cluster is hosted in the Google Cloud, let's grab the Google Cloud token, have the token, and let me function the token, and it says authentication successful, and gives us two options, whether we want to perform all the checks and individual checks. Let's start with by performing all the checks. It will gear up by scanning for a wide range of IAM misconfigurations in the cluster, such as admin roles, read admin roles, secrets roles, privileged roles, etc. Then it moves on to detecting a variety of misconfigured containers, and then initiates scans on misconfigured policy security policies and network policies. Not only that, it can also assess the excessive privileges of the subjects inside the cluster, and also run commands on the containers and streams back the output. Let's see an example how we can execute commands on the containers. If we list all the ports that we have in the container, let's choose this port, and it will list the containers that are running inside this port, and it says execute, enter the command that needs to be executed. There you go, it streams us the output. Click on exit, it says the scan has been completed, and the results generated with the target file name. After a couple of scans, we will go through the results. Well, in the second scenario, let's scan a cluster that is hosted on the Amazon EKS. For this one, let's use the second option, ContigPile. I have so many clusters in my queue ContigPile, and this is the Dev cluster which I use for our demos. I have chosen the cluster. It goes through all the basic checks that we have seen in the first scenario, and once it identifies the services, it says this port has been identified, and this is the version of the Kubernetes, and let's go through the authenticated scan. Because this is hosted in AWS EKS, let's grab the token for this one. EKS token, there we go. I have the token now, and now let me punch in the token. It says authentication successful, and you can perform all the checks. So the tool supports all kinds of Kubernetes cluster hosted in Amazon EKS Azure, EKS the Google Cloud, or it could be like OpenShift or IBM Kubernetes Engine, or even your self-hosted Kubernetes clusters. Well, in the first two scenarios we have seen scanning like the Kubernetes clusters. Now let's look at scanning a Kubernetes worker node which will have important components such as like KubeNet, ReadWrite port, ReadOnly ports. Although these are like not enabled to public by default, however, some engineers like me might end up enabling it for testing purposes and then forget to revert those changes once the testing is done. This issue might escalate over the time, especially during the pandemic where most people work from home. So this time let's quickly scan a worker node, and because this is a worker node, it will usually not ask us for an authenticated or an unauthenticated scan because the services that run on the worker node are quite different from the master node. And yeah, the scan has completed and it says like it has identified the ports such as like KubeNet, ReadWrite, KubeNet, ReadOnly, KubeRoxyHealthCheck, and there is an Open422 and also the Kubernetes dashboard endpoint identified. And it also tells us like what are the endpoints that have been identified? For example, on KubeNet, ReadWrite port, these are the endpoints that have been identified. And on the KubeNet, ReadOnly port, these are the endpoints that have been identified. So we have completed our scans. Let's look at the results. Every time a scan is initiated and once the scan is done, it will create a report, it will generate a report with the same target filing. For example, we have scan cluster with the IP address 3411669. It generates a report with that one. KubeStrike creates a very elaborative report. It says what all ports it has scanned for and once identifies it says, hey, endpoint has been identified on this IP on this port. And it gives us all the information such as like admin roles, ReadOnly admin roles, the destructive roles and the secret privilege roles. It also give us very clear information like, hey, this is a role which has privileges to secrets. And this role has been attached to these service accounts. This service account can access secrets in this name, space, and the next. So that way it gives us like a clear visibility like who have what kind of privileges inside the cluster. And then it will give us the information about the privileged containers. Like, hey, these are the privileged containers. It will also give us the information why a container is flagged as a privileged container. For this container it has like allow privilege escalation flag enabled true. And there are some other containers which are sharing like the host networks. That is the reason why these containers have been flagged as privileged containers. It also lists all the containers where the liveness probe is not set, the readiness probe is not set or where the CPU and the memory limits are not set and the priority class name is not set. And the containers where the service account has been mounted. And also the containers where secrets have been mounted and the containers where the Docker sockets have been mounted. It also give us the information about the Kubernetes worker nodes and the privileged port security policies. It will also tell you why a particular port security policy has been flagged as a privileged because it has different flags enabled. But what I have showed you so far are the capabilities of the first version of the cube striker which was released four months ago. Since its launch, it has received a great response and it has been viewed more than 10,000 occasions. People have started using it to scan their infrastructures and I had been asked to develop more features. This gave me the guidance and encouragement and that I needed to build the next version with more advanced capabilities and an easy to use interface. Here is the new and the improved version of cube striker. This new release has a front end and now provides security for containers running in the cluster by continuously discovering, tracking, scanning and reporting them using open source scanners. The new version of cube striker can be installed anywhere such as your workstation or an Amazon user instance or an Azure virtual machine or indeed any machine which has access to the target Kubernetes clusters that you want to scan and secure. Well, if you're in this talk, you are likely familiar with the concept of containerizing applications. Currently, the cube striker of the application is made up of three containers, a front end Angular app, the back end Python service and DynamoDB. The new environment can be installed using either Kubernetes Ammo Manifestation files or Helm charts or even using Docker compose. Let's look at a quick demo of using the new version of the cube striker. So we have like our Ammo Manifestation files and now let's deploy these files which will basically create a service and the deployments of the front end back end and the DynamoDB. It created all the service, there we go. And in order to access the Kubernetes of application, we need to grab the load balancer or the IP address of the front end service. There we go. That is the load balancer IP address. Let me put it in the browser. And the very first time, it takes like a couple of minutes because not because it usually takes like a few seconds in order to interact with the underlying instances. And once everything is done, it will start working. And there we go. That is like the new version of the cube striker which I'm about to release in the next one week. So it will give us the information of the clusters and the containers inside, running inside the clusters. And you can add or scan a cluster by creating that button and you can add AWS, Azure, Google and generic clusters which are like self hosted or open to. And in order to scan a cluster, you need to provide the name of the cluster and then the IAM role which has enough privileges to scan the cluster and the region where the cluster has been hosted. And once if you create, it may take anywhere close to seven to eight seconds to scan the cluster and show the results on the dashboard. There we go. The scan has been completed. It says the scans total number count one and here are the results that we have on the screen. So it says it has to scan total 149 roles of which 113 are misconfigured, so total seven misconfigured containers and power security policies and 12 policies, total nodes. And if you want to see further down the results of each and every cluster, click on the cluster name. It will give you the version of the Kubernetes that is running inside the cluster and the version of the Docker and the total count of them's configured roles, containers, power security policies, et cetera. And if you further go down, whatever we have seen using the CLR, it will give us all the information like admin roles, read admin role, secret roles. You could also give us the information why a particular role is called an admin role. For this one, the web app has the works, start resources, which means this particular role or any service account that has this role attached can perform any actions inside the cluster. So the destructive roles anywhere, any role which has the privileges to delete something is considered as a destructive and any role which has the privileges to play with secrets inside the cluster is called the secret roles. And then if you look at the misconfigured containers, it will give us the list of all the privileged containers, containers where liveness, probe, readiness, probe, CPU, memory limits are missing. And when we click on a particular container, it will also tell why that particular container has been marked or flagged as a privileged container. In the misconfigured policy policies, it will also tell you why a particular policy is flagged as a privileged one. For example, if you look at this one, it has flags such as privileged, as any user, start, capability is allowed and privileged escalation flag has been enabled. It also gives us information of the nodes for the cluster. And now let's quickly add a couple more clusters, the demo clusters that I have. So let me quickly give the cluster name and the IAM role and the region. Let me quickly add one more cluster. In fact, it just takes like a few seconds to scan your cluster and identify all the misunderstand configurations. In the next four to five seconds, we should have all the information. There we go. The page has been refreshed. And we have all the telemetry reports or the count of the clusters on the main dashboard. And when we go to the clusters section, we can see the different clusters that we have. And if you click on each and every cluster, it will give the individual results of that particular cluster. And on the containers section, you could also give you the list of containers that are running in each and every cluster. And I strongly believe that security should be baked into the DevOps process. And the security tool should also flow very freely through the DevOps pipelines, giving the developers more autonomy and authority without compromising the security or elevating the risk. Keeping this in mind, I made Cube Striker the ACD integration with DevOps pipelines tools, such as like Jenkins, Azure Pipelines, or Bitpocket Pipelines, or Bamboo. This basically allows for continuous scanning of the infrastructure to identify any misconfigurations prior to the deployment into the sandbox or the production environments. Like I mentioned before, the Cube Striker, Cube Striker, this new version of Cube Striker, also incorporates the ability to see some critical resources in the Kubernetes infrastructure and the ways in which it could be compromised. You can see like a visualized attack parts of how hackers can advance their attacks by changing different components in the Kubernetes cluster. This feature is currently in the beta version and will be further improved as a threat analysis in the visualization tool. For example, if you click on the roles, it will give you the list of all the admin roles, the structure roles, previous roles, and if you click on the admin roles, on the cluster-wide roles, it will say which subject has access over the cluster-wide and what resources they can access. And in any particular namespace in the namespace for Cube system, it says these are the users and they can access these resources. Or if you choose like admin roles, it will give us information like cluster-wide. These are the users that can access everything inside the cluster or in a particular namespace it says in this namespace, these users have admin access. I'm currently working on enhancing this feature and working on setting up all other features where it will give us the complete visibility of the entire Kubernetes clusters and the ways, the different throughputs that the hackers can use and gain access to your clusters and perform previous installations. And I'm also currently working on setting up documentation for this website. This new version of CubeStriker will go live on May 9th and also the documentation site will be available. The documentation site will have all the information such as how to use different versions like CLI and the web app, how to use them on different infrastructures such as AWS, GKE, AKS, OpenShift, self-managing, scanning, worker nodes, et cetera. The new web app version, as I mentioned, it will be released on GitHub on May 9th. However, the command line interface is already available on the GitHub. So the link is shown on the slides. Please give it a test drive yourself and then share your thoughts. Any feedback or any suggestions or improvements are always welcome. And needless to say like innovation needs collaboration. So while the CubeStriker community of adopters and contributors are growing steadily, I hope to continue the expansion of its use by collaborating with more users and get more contributors on board. If you are keen to learn more and get involved, please get in touch with me through any of these channels. And I would like to thank the organizers for giving me this wonderful opportunity. Well, that pretty much, that's it. That concludes my presentation and I'm happy to take any questions that you have now. Yeah, awesome presentation. Awesome. Awesome. So yeah, it's Q&A session. If you have any questions, please feel free to ask or use the chat section on this platform if you're streaming live or please feel free to ask your questions and please feel free to like as well. And yeah, just like person mentioned, feel free to check out these URLs and to learn more about the CubeStriker and also feel free to follow Basant or his social media channels. And yeah, thank you once again, Basant. I think that was really cool. That was really insightful. And I hope this is more or less the humble request. I would like you to share your slides as well with some of the attendees if possible. Yeah, cool. Cool, I'll definitely post. I'll upload the documents on the Google slides and I will share the link with you guys. Thank you so much for giving me the opportunity today. All right, yeah, I think we, okay, okay, cool. Actually thought the question came here. Nice, thanks a lot, Basant. Yeah, I hope to see you some other time. Yes, thank you so much guys. Yeah, you're welcome.