 Hello everyone, I'm Rahul Jadav. I'm going to talk about the challenges of securing Kubernetes deployments or pods at runtime. Before going into the details, there are two things that needs to be highlighted. Why should one bother securing the pods and why does the runtime approach matters? If you look at the Kubernetes threat model, broadly there are two types of attacks possible. One related to control plane attacks wherein the attacker tries to compromise the cube API server on the master node or the cube right on the work nodes. The control plane is open only to administrative domains and the attacks are usually insider attacks. Also the control plane implementation is much more hardened and secure as compared to data plane implementations. The data plane attacks on the other hand are more common wherein the attacker leverages unknown or unknown exploit within the application itself. The application developer usually is more focused towards application logic and has less cybersecurity focus that results in poor use of security controls. Secondly, with Kubernetes, pods is an execution unit which means in many cases, pods will be facing the external workload even though the request may go through an ingress controller. This means that an attacker can leverage and exploit inside a pod. Another point to note is that within the pod, there is unrestricted access to all the internal containers. A typical example I use is that the service account token mounted as part of the pod typically needs access only by a few processes but the access is left open to any binary within any of the containers within the pod. Almost every attack in Kubernetes makes use of this fact that the injected exploit binary will have direct access to this service account token. The service account token is then leveraged by the attacker to do lateral movements. The pods are becoming increasingly becoming the gateway to all the attacks as witnessed in the case of log4j, log version and master departments. Depending on the workload lifecycle, the security elements can be bucketed into three broad categories, namely static, admission time and runtime. Vulnerability and configuration scanning engines fall in the bucket of static scanning. The aim is to identify known vulnerability or known configuration issues in the CI pipelines itself. Admission time controls allow you to specify policies that checks the Kubernetes deployment manifest and ensures that any resource that is to be persisted follows the security rules. A typical example would be an admission time rule that disallows pods requiring privilege mode. Runtime controls are enforced after the workloads are deployed and executing. One example would be network policies for the workloads are enforced only after the workloads start executing. There are other runtime policies that observe the execution behavior of the workloads and try to constrain its behavior based on the security policies. Now the question is, where and time matters? There are two premises here. As an organization, you might not be in a position to patch all the known vulnerabilities since there could be literally thousands of them. And secondly, there are unknown unknowns that is zero-day vulnerabilities. The security, the runtime security are more precisely zero-trust runtime security is something that can fundamentally attack this problem. And I'll talk about some of those challenges achieving this today, achieving that today. But before I talk about policy controls, let's look at some of the behavior that pods possess and needs to be constrained. Network behavior has been a topic of study and implementation for long, but not necessarily from zero-trust perspective. Process behavior and file access behavior have relatively received much less attention in containerized world. Really, the two big questions are, how to identify the allowed set of behavior and how to enforce that behavior restricting everything else without breaking the application. Now the question arises, what exists in the Kubernetes world that can apply constraints on these aspects? There exists pod security context using which one can define privilege and access control settings for a pod or container. Security context settings allows one to specify app armor, seccom, SLNX profiles at the pod or container level. It also allows limiting the set of kernel capabilities within the pod. Note that the user needs to identify the set of controls such as what capabilities are allowed, what should be the native app armor profile, what system calls are allowed. This is the non-trivial task. It is possible that the user of the security context identifies the security posture manually once, but the security portion needs to be updated with the application updates. The application updates are more frequently the cloud deployments and thus the security context becomes invalidated soon. Without automation, it is difficult to identify the security posture changes. The security context requires one to specify native app armor or SLNX policies. Now different cloud providers support different Linux security modules. For example, Google Container Optimized OS supports app armor but only by default. Amazon Linux 2 supports SLNX by default and Border Rockets supports SLNX and BPFLSM. This is thus, it is a nightmare for a security administrator to operate in multi-cloud environment. In fact, even within the same cloud, there are good chances that there are a mix of nodes supporting app armor and SLNX, making it extremely difficult to use the pod security context. Most of the managed cloud service providers provide hardened worker node OS images. Given the shared responsibility model under which they operate, the security buck stops at the host or worker node for them. Thus assuming that the managed cloud service provider will take care of the pod security is a misnomer. Google Container Optimized OS spotted rocket provide excellent host hardening solutions listed here with but that would not protect the workloads or pods that are exposed directly to that actor. One of the zero trust tenant is to identify the least permissive security posture of an application, which means identifying the allowed behavior and denying or auditing everything else. Note that the same container image might behave in different ways in different environments. It is important to identify the application behavior in its given deployment. This mode could essentially enable protection from for on 50 is zero data tax. However, identifying the security posture is non-trivial. There are real risks of impacting the application runtime behavior and in worst case, causing application down times. There are few things necessary in the framework to consume the least permissive security posture. One, the ability to operate in dryer and mode. The user needs to be confident that there are no false alerts generated by the system until they flick the switch to default in a mode. Ability to learn from the false positives and reinforce the policy. This may require manual intervention at times. Ability to correlate events on different spectrum. For example, if there is an unwanted sensitive file system access and at the same time, there is an attempt to make a network connection to an unknown IP, then the severity of the alert should be high. The need for securing the workloads has been time and again highlighted recently by NSA and more recently by CNC of cloud native security white paper. There is a clear need, but the question is, is there sufficient tooling available for implementing such controls in a more user friendly way? And at the same time, reducing the risk of application down times. Highlighted here is some of the CNC of tooling available in the context. Cubama and security profiles operator are two projects that have the ability to, A, enforce LSM based security policies. The second is the important point to note is that they both have a way to record the application behavior and automatically derive a set of policies from that. Identifying the least permissive security posture. The policy violations or alerts needs to be knitted with the Kubernetes metadata and both these engines have the ability to do that. To summarize, it seems like runtime security is an imperative that is the deployment or pods needs to be hardened. However, the tooling available today may not be enough, especially in the context of dynamic application updates. The zero trust runtime security is challenging to achieve, but it has the ability to protect the movers from future attacks and not purely rely on signature based prevention methodologies. Thank you.