 Hey, everyone. Thanks for joining this panel discussion. Demonstrifying zero touch for cloud native applications. So before we go into topics, what we are going to discuss, I would like to introduce my panel here. We're sitting and then first all this stuff before we go to the panel, I just want to highlight that all the topics presented in this discussion related to individual views not associated to any organization. Let me introduce myself. I'm Kishore Nadella, senior leading leading manager and a cloud security team and working on multiple cloud technologies and solutions. So, as you see here, and I'm a great good advocate on the NSOS and open source projects and recently practicing in NO inclusive speaking. So, and in my past I worked on a lot of cloud, multi cloud digital transformation process and in that said I'm going to introduce and pass on to Aradhana. Hey everyone. Thank you for joining today. I had cloud security for TIAA, including DevSecOps and application security. I am co-chair for CNCF TAG security, CSI research fellow, and I'm also co-chair for civilized working group. I have contributed to a number of NIST initiatives and I'm an inventor. Thank you. Hey, my name is Mariusz Sabat, and I'm the senior software engineer in IBM Research. My interests are around building scalable distributed environments. I specialize in addressing challenges for workload identity in multi cloud and hybrid cloud scenarios. I have done several patents in this space, and I'm an active contributor to the open source. I'm also a member of the Zero Trust working group under CNCF security TAG. Thank you. Hi everyone, Philip Griffiths from Net Foundry. I do technical advocacy for the company. So, talking to people with pains, communities, open source forums, events, and lots of writing blogs and content. That covers work that I do within the CNCF in the Zero Trust working group, but I also do some stuff with the cloud security alliance and some other security based places. I'm generally a technical generalist, so I know lots of things about lots of different topics. At the moment, very focused on Zero Trust distributed systems and automating the systems that we use. Hi, my name is Asad Fawzi. I'm a Seattle based entrepreneur and technologist. Over 20 years experience at senior level technical positions in large enterprises including Microsoft, PayPal, Intel, and Netscape. I founded multiple startups. I've published more than 50 articles, blogs, tutorials, and cloud native technologies. And I'm also a member of security TAG, the supply chain and security TAG Zero Trust working groups of CNCF. Thank you. Thanks everyone. So before I hand it over a couple of questions to panelists here, I just want to say the Zero Trust has been there for years in the different forms but no the failure of traditional security models not working as a lot of workloads are moving to cloud native. With that said, some of the hybrid IT contest is in place and now I want to pass it on to Aradna and ask a question. What do you mean by Zero Trust and why do you think everyone has to focus? Thank you Kishore for that question. So as you all know, Zero Trust is a term used for evolving set of cybersecurity paradigms which kind of break the traditional model of network based security right at the perimeter enterprise and the parameters are vanishing and because enterprises are going to BYOD remote access cloud cloud native technologies so you're in a distributed world of connected software. So the main philosophy behind Zero Trust is to not implicitly grant any trust and based on that trust grant access. So every access is granted on a dynamic basis and based on the attributes of the user application and device on the context the decision to allow access or deny access is made. Again, as you said it's not a new concept it's just that in the new paradigm the threat landscape growing so much the traditional security methods are not valid. And Zero Trust literally touches every part of the enterprise IT like network and environment applications, users, data, devices, automation and orchestration as well as visibility and analytics. So in terms to the cloud native technologies, there are descriptive languages you can use, home charts, terraform as well as, you know, custom resource definitions to pre define the desired state of infrastructure and applications that you want in your environment. And that allows you to define what type of access and what application behavior is desired or accepted. So that is a key enabler for Zero Trust in cloud native platforms. So with that, I think I'll hand it back over to you. Thanks Arana that was a great perspective about cloud native. So, Mario's question to you, what does Zero Trust mean to any organization, what are the principles someone really need to look into that. Thank you Kishore for this. Zero Trust, like Radna said, it's not a specific product or a single tool. It's more like a strategy. So let me give you an example. With COVID, we experienced a shift to a remote work. Now companies and organizations could no longer rely on the perimeter control, meaning the implicit access based on location to the building or to the office, whether physical or network is not sufficient anymore. So this is when the Zero Trust principles really took off. And this leads to your second question, what are the principles of the Zero Trusts. First, always verify, never trust, eliminate implicit trust, assume a breach, plan for compromised systems and compromised elements, a principle of least privilege that we'll talk about this in a second. Authenticate and authorize each operation before the connection can be established. Use the strong identity, like X509 certificates. In one sentence, right user has access to write data for the right reasons at the right time. So back to you Kishore, what does this all mean for the cloud native world. When we say cloud native or before cloud native, traditional people are used to be traditional VMs. And they were when they're migrating the VMs to from the legacy servers to VM, and firewalls are pretty easy. I know they followed what, what was their, what was implemented in legacy servers. But when we say cloud native, most of the workloads are moving to microservices, containers, etc. So microservices are, and containers are short lived. So you need to, you need to deal with the security are all together differently. So, when we have this short lived containers, we need to have these policies, and the firewalls are not giving access to these workloads needs to be created separately. So where we, we need to have a strict verification what this part or container can really talk to other workloads within the network outside a network, etc. Not only that I know when we deploying these workloads into the cloud or multi cloud and hybrid cloud environment, we need to make sure it works continuous delivery pipeline goes also having implementing necessary security controls. But not least, when we are deploying the parts, there is no IPs IPs are constants changing so you cannot define the firewall firewalls on top of IPs. So you need to have the policies which is beyond which these policies needs to go with the labels and all the DNS, etc. So don't use a rather, rather than using IP addresses. So the security professionals needs to change their perspective instead of using IP addresses, change their, their implementation solutions to implementation solution to know cloud native security procedures. No, that's all I can say about cloud approach. So with that said, I would like to pass on to Philip to talk about what are the building blocks we since we'd already talked about zero trust and cloud native and all that stuff. What do you think is a way to know some of the building blocks somebody needs to consider as good questions. Thanks for sure. For me, it very much maps to the, the definitions of the pillars within zero trust so I think one of the foundational ones is identity. So how do we provide x5 nice tickets and use JWT's so that, as you say, instead of trusting IP addresses we can have we can have strong identity as as root for whether we trust something or not a component of the the the platform. That that's both the platform that's that's the platform. It's also workloads. It's also users because we see in our platforms being distributed beyond just you know multi cloud but also into edge IOT and and you know users accessing those applications as well. We then have to consider whatever workload within this system of this platform. That's part of the operations or it's connecting in how to make sure that workload is protected. You know with your protect against next generation threats, viruses malware, you know, etc. Then we need to consider how the applications are developed, how we make sure the software development pipeline ensures that we're not bringing in vulnerabilities, how we make sure we can we can essentially run those applications in a secure enclave in production so that we're not bringing in the runtime less trust and how we can how we can automate that full process from from from left development to right production, you then got the network between this so as you said again, we don't want to trust IP addresses because they're dynamic they're not they're not static they change around it's it's it's distributed. So we need to build an overlay network or service mesh that enables us to to ensure strong identity, micro segmentation least privilege, authentication authorization before connecting all those those wonderful principles, and then we need to ensure that we have visibility and monitoring of the solution so that we can control policy governance. So there's, there's, there's almost the overarching bit of how do all these things integrate. They cannot be single point solutions. There needs to be a way in which you tie them all together, so that you have, for example, if, if, you know, if you can't get on to to the overlay network, or if your your endpoint or host has been compromised, it's removed and remote access, and it's by bringing these blocks together and then build that whole sum that we're able to to build zero trust principles into a cloud native platforms. Thanks feeling. I think, I think, talking about micro segmentation and controlling the policies and is a great thing to have. Asad, do you think any other building blocks somebody needs to consider on their cloud native journey by implementing zero trust? Sure. Thanks. Thanks, Kishore. I tend to speak very quickly so fast. So I'll try to slow down today so that you can understand. Everybody can understand Philip has done a great job laying down the foundation, but I want to talk about three key building blocks of zero trust and cloud native application. One is the access base control. Two is the data encryption and least privilege access and three continuous monitoring access based control is the key aspect of zero trust and cloud native application. It is a security model in which access to resources is granted only on need to no basis, and all access is verified and continuously monitored. This is in contrast to the traditional security model which rely on perimeter based security and trust all devices and users within the perimeter. In a cloud native environment access based control can be implemented using identity and access management I am solutions. These solutions are used to manage and verify the identities of users and devices accessing the network. This includes user authentication and authorization as well as multi factor authentication MFA and single sign on SSL capabilities. Overall, access based control is a crucial aspect of trust, zero trust in cloud native application. It helps to ensure that only authorized users and devices have access to the sensitive resources by implementing access based control organization can reduce the risk of security incidents and make it more difficult for attackers to compromise the system. So access based control can also be used to enforce least privilege access and cloud native application, which limits access to the minimum necessary to perform a task and revoke access as soon as it is no longer needed. Access to data is granted only on a need to know basis, and all access is verified and continuously monitored. This includes granting access to specific resources, such as data or application, or limiting access to specific actions, need or write access. Then there is data encryption, both in transit and at rest to protect it from unauthorized access. This can include using encryption for data stored in the cloud, as well as encryption for data stored in the device or in transit across the network. Continuous monitoring is an essential component of zero trust implementation in cloud native application. It is the process of continuously monitoring the network for suspicious activities and taking action to prevent and respond to security overall access based control is a crucial aspect of zero trust in cloud native application by implementing access based controls organization can reduce the risk of security incidents and make it more difficult for attackers to compromise the system. Back to you Kishore. Thank you. Thank you for a detailed explanation about all those building blocks, Philippa and Aranna back to you who heard about the cloud native and building blocks know what team is talking about it. So with all this said, what are the challenges somebody needs to think about it to implement zero trust. Interesting question. And lots of challenges in my opinion. So IP addresses have been central to the traditional network security. When you go to cloud. They're not visible they're ephemeral they're constantly changing. And you add Kubernetes to that where you have dynamic ephemeral resources which are spinning up and spinning down very quickly. So all of this at the pace at which it happens is quite challenging. That's the first thing. And Kubernetes itself is, you know, wide open you're required to figure out how to secure your Kubernetes platform, the control plane, the data plane, and the API is, and all the interface and then you're required to literally you should have an overlay on top of it to further improve your micro segmentation even though Kubernetes provides network security policies that you can deploy and how Kubernetes works. I mean, cloud native, we have server less and we have other technology as part of it too but the heart of the problem is still Kubernetes right Kubernetes is the underlying technology in Kubernetes. And there's I expected to figure out all the controls for this and then in the CI CD pipeline pre deployment all the checks you have to do right software supply chain security making sure all the third party libraries are integrated probably and all the policies infrastructure as code policies that you're deploying to manifest in the YAML validation that you need to do, and then in runtime, you need controls as well right. So it is it creates a very dynamic environment and lots of components to manage and Kubernetes essentially it doesn't, it doesn't take the context of a enterprise network right there are no IP addresses there's no fixed boundaries. So these are ephemeral dynamic services, and basically the security the way it works is it just keeps track of who's doing what and when right, and when you have thousands of these services dynamically spinning up that creates a whole different paradigm of security that you need to access. And all these policies and keeping track of these policies constantly and updating them dynamically to keep your environment secure brings a whole different dimension or security to a cloud native platform. And the technology is still evolving right every day we have new threads and we need to figure out to mitigate those and like Assad said this continuous monitoring monitoring we have in all systems but in cloud native you have to use that monitoring intelligence to feed back into your policies, so you're continually raising the bar in terms of security of your platform so all these complexities bring great challenges for the enterprises to secure them. Thanks Aradhana, dynamic environment, constantly changing technologies. Thanks for all those pointing. So, Marius, back to you. With all the challenges Aradhana mentioned and whatever the topics we talked about, do you ever see is there a golden power to implement. Okay, well let's start with identity. They have to be authenticated and authorized to be able to do anything in a cloud, and that is nothing new. Even across multi clouds, we already have concepts like single sign on, and that's problem already solved. The interesting challenge however is the workload identity, microservices or containers that represent the service need to communicate with each other. They access API's, they pull data, make calls, etc. And with the zero trust, each transaction must be explicitly authorized. So every cloud handles identity in fairly similar way. It comes with IAM identity and access management that is integrated with the platform. This identity provider consists of certificate authority or root of trust to provision identities for workloads. When the container wants to access a service or database, it takes that identity in form of the X509 certificate and presents it to policy enforcement point, which verifies this identity with identity service and then based on the policies, it either grants or rejects the access. So when the organization uses multiple different cloud providers, things become even more interesting. The providers need to be able to securely communicate not only with each other, but also between different clouds. So how do we do it? We cannot use static key because the key generated, like API key, is long lived, and we lose control of it when the system is compromised. We don't know how many copies of the key were created, who actually has access to the key, and to move the API key between clouds, it often requires a human to perform this action. So we put a lot of trust in a person that must be certified to handle certain data for compliance reasons. So we could potentially use federation. The idea is that we teach IEM system of one cloud, how to interpret identities of another cloud that is calling the service. But support for local identity federation across clouds varies. Workout identities are defined differently by different cloud providers, they don't necessarily translate well across clouds, and since the schemas are different, it makes very difficult to establish a trust relationship, or to make meaningful access policies. Similarly, since federation has to be done between each cloud, as the organization scales up, the configuration management becomes a nightmare, it's a quadratic complexity. So to solve this, we can use something like SPIRE that manages workload identities between clouds in universal way, since it's cloud provider agnostic. There are no more hard coded static keys. Then we can support common identity schemas that are not tied to any specific cloud, and that simplifies this access policies. All these examples, all the solutions are based on CNCF projects, and we covered this in details in our white paper, so please check our work. That's however another challenge. The workload identity is tied to Kubernetes, to the platform or to the cloud provider. So can we really trust the host? Do we know what's running there? Underlying software stack might be tampered with. What about the on-prem or edge deployments? Can we trust those? We can do attestation. We can attest the node that is hosting the workload to guarantee its identity beyond any doubt. Attest the software stack all the way from booting all the way to kernel. Enforce the software bill of materials, we can measure and enforce the integrity of the files, and we could revoke when the attestation fails. All these attestation aspects, including the hardware root of trust, cover well in our paper. So I hope this helps. So now Philip, can you tell us about network infrastructure applications? Yeah, network aspect, definitely. I think the starting point is how we implement our zero trust networking principles to cover communication with the objective that we can ensure safe, fast and reliable communication and virtualization of the network to whatever resources are in our system, whether it's a client-to-server, for example, someone accessing the Kubernetes API, or server-to-server with clusters communicating, or machine-to-server as we move into IoT and Edge use cases. And picking up from where you started, what's really fundamental is that you start with identity such as an X5, a nice certificate, so that you're doing authorization and your initial point of trust based upon that rather than IP addresses. And once we are ensuring that all communication is taking place on the basis of mutually authenticated identities to establish connections, we can also start looking at how we can implement authentication authorization before connectivity. That's almost the opposite of how most networks operate. You send a packet and it goes, oh, should I let it in? No, you should be authenticating that the thing has access to the data plane before it's able to get access to the data plane. So we're really following a software-defined network in architecture where we're splitting those two things, the control plane and the data plane. We're then further able to implement application micro segmentation where we can do attribute-based access control and least privilege to specific IP addresses or specific identities or specific DNS and other aspects of how our applications want to communicate, and potentially even down to a specific service, which can have a zero trust network built into that application. And this enables us to get to a point where we can create a network which is closed by default rather than opened by default as traditional networks were built. We should all be built in a way that is driven by software and APIs so that we're ensuring that we can have the agility of distributed systems and be able to move as fast as the software developers and platform wants to move in itself in a way that is highly automated. Once we start being able to achieve that, then we start being able to eliminate traditional network and approaches like access control lists and whitelist inbound IPs on your firewall and VPNs and other such things so that we make it much simpler. And there is various aspects which are covered in our white paper which would be great to have people looking at and it really, you know, there's different technologies which can do this, whether you're talking about service measures, whether you're talking about zero trust overlay networks, some API gateways have the ability to implement parts of this as well, and it really becomes a question of how do I want to implement what are pros and cons I'm looking for. And a quick comment, I feel we should highlight that just having micro segmentation based on Istio service match and, you know, all traffic encrypted between applications and services. It also prevents reduces our tax service greatly if one application gets compromised, rest of your real estate of applications and microservices is still secure. And that's the advantage that Istio provides and Istio has evolved quite a bit over the last few years, and now they are they are even, you can even enforce application security policies in Istio right and so on and so forth so just wanted to highlight that. I don't know totally I understand that. So Marius and Philip has covered quite a bit and in great details and done a wonderful job of covering the aspects of golden path, like for example Marius covered identity and attestation Philip has covered network environment micro segmentation. It's a tough act to follow, but I believe there is no one golden path to implement zero trust for cloud native application for for every organization, but there are some general guidelines that organizations can follow. At the heart of zero trust is the principle of least privileged access. It is implemented in cloud native application by controlling and managing access to the resources. This ensures that only authorized users have access to the sensitive data and that access is limited to the minimum necessary to perform a task. This can be achieved through a combination of different security controls, including number one, while I am is used to manage and control access to resources at the level of individual users and devices are back on the other and is a system that is used to control access to resources at the level of roles and permissions. It is used to define roles that specify the actions that users or grip of users are allowed to perform on a specific resources are back for example is used to control access to resources in a Kubernetes cluster. I've already covered micro segmentation so I'm going to skip that. I talked about data encryption earlier, both in transit and address including in the cloud and devices and in transit and cloud native application is important. Since it ensures that even if the data is compromised, it will be unreadable without the encryption keys. There are other algorithms like AES and RSA can be used for data encryption. Encryption keys can be managed and protected to ensure that they are not compromised and can only be accessed by authorized personnel. Cloud native environment is dynamic. It is essential to have real time visibility and monitoring to enforce the zero trust access base control in a cloud native environment. Continuous monitoring can be achieved through the use of security information and event management SIEM systems, security orchestration, automation and response SOAR platforms and other security monitoring tools. These tools can be used to collect, analyze and correlate security related data from various sources. In cloud native application, access logs and auditing are used to track and monitor access to data and resources. This allows organizations to identify, investigate any suspicious access attempts and quickly respond to any security incidents. By implementing these security controls, organization can ensure that only authorized users and devices have access to sensitive data and that access is limited to minimum necessary to perform a task. Back to you Kishore. Thank you everyone. I know the golden path approach with all the building blocks you guys provided is a great value for the teams who are listening here. So now Aradhana, you heard about golden path building blocks and then summary of cloud native technologies. So how somebody is working on cloud native applications or the organization can take this one further. What are the first thing they have to do? You want to summarize this. Yeah, in short, I think everybody has to go to Zero Trust eventually because now it's a mandate from President's cybersecurity executive order, especially if you're doing business with the government. Again, the threat landscape has evolved so much. Every organization is targeting, or at least is working towards Zero Trust, especially with all the ransomware attacks and those threats as well. They have increased quite a bit. If the organizations are in the cloud native platforms already, then they have golden path, right? They know what is secure and the more you can do on the pre-deployment side and force identities, validate your software supply chain security and those policies for what can be deployed and what is your desired state and what application can access, what services or what data or what users or devices can access what applications and services. The desired state as the more we can, enterprises can identify and define upfront, the easier it becomes. But again, this is an evolution. This Zero Trust is not the first day. You know, there's no easy button that overnight you are Zero Trust. These policies will grow evolve over time, but you start somewhere right even to grow and evolve. You need to start taking some baseline controls and policies, deploy them in your pipeline and in your runtime environment. Start gathering intelligence and as you get more and more feedback, you enhance those policies. And having strong identity and authentication infrastructure is important. You need to have, you know, like, Maria said, Federation and, you know, open ID connect and speed feed is to be able to enforce and or identify applications in the runtime and the whole image programs validation in the runtime, what images are in your repository and what are the running in the runtime, as well as how you're securing your repos, what gets into your repos, who has access to what in your repos. I think these are some basic hygiene best practices in a cloud native platform that will help you to get towards Zero Trust. But the more you can define the desired state upfront, who accesses what and how they are segmented and what policies need to be deployed for what workloads. I think easier it gets for the enterprises to be able to achieve Zero Trust over time. And I think, you know, start small and improve on top of it. That's a great advice. So with that said, I'm going to share my screen back. So that concludes our panel discussion here. And we're listening, you know, we, here is a team, you know, the five families here working on a cloud, I do a tag security team, we're working on Zero Trust, white paper, and we have white paper links over here and we have weekly meeting. And every Friday we meet. So we are welcoming you to join us and participate in writing in this white paper or suggesting us and correcting us. Whatever the help you guys can provide. It's a great help. And thank you so much for joining.