 Hello, everyone. I am Raghushri. I work as a Cloud Security Specialist at Nokia, and my expertise lies in securing applications, infrastructure as service, and platform as service offerings via OpenStack Cloud, containers, and Kubernetes. I'm also the CNCF Pack Security Community Manager and the lead for the Cloud Native Security Lexicon project. Today, in this talk, I'd like to introduce and discuss the Cloud Native Security Lexicon project. A little about why it was initiated, what this paper is all about, and we'll walk through one of the sections of this paper to give a feel of it, and what we intend to do in the future with this project. To begin with, we all are aware that Cloud Native ecosystem is growing. It's growing at an accelerated pace, and the number of Cloud Native projects is huge with tons and tons of contributors all around the world, working extensively to build the latest and greatest products. Just to give a view, the number of projects in the CNCF Cloud Native landscape is itself 1763, with more than 1,34,000 contributors from around the world. Many of the Cloud Native projects perform not just one, but multiple functions. For example, Istio. This is not just limited to observability, traffic management, and things like that, but also plays a pivotal role in securing microservices as well. Speaking of security, security is an indispensable part of any digital and transformation initiative, and has been in the industry since time immemorial, with changes in the technology and the increasing maturity of the Cloud Native landscape. Traditional security practices needs to be redefined to include the new and novel ways to solve security challenges that are existing in the current time. To help educate this massive community about the best practices for securing Cloud Native projects and deployments across these projects, TAX Security released the Cloud Native Security White Paper. This paper intends to provide organization with clear understanding of Cloud Native Security, its incorporation in the lifecycle processes, and considerations necessary for determining the most appropriate application thereof. Post the publication, along with the numerous positive responses, we have received a number of requests to provide a glossary or a lexicon available for these commonly referenced security terminologies to ensure that they are not overused, used as umbrella terminology, or incorrectly presented in an irrelevant scenario. With this, the Cloud Native Security Lexicon project was initiated with the sole intent to standardize the terminologies specific to Cloud Native Security and to bring about clarity to all the community members, including Cloud Native practitioners, developers, operators, regarding the right set of terminologies to be used in the right context across the software development lifecycle, as well as their operational environments when it came to securing them. To begin with, we had the strong reference of the Cloud Native Security White Paper, from which we handpicked the commonly referenced security terminologies and further elaborated them to provide a definition for each of it, the organizational use for each of them, and references to any definitions from the governing bodies as and where relevant. Today, this lexicon is a huge collection of 40-plus terminologies grouped across four different categories, that is generic security concepts, identity and access management, hardware and security tooling. The first section, Security Concepts, covers the typical security concepts, such as attack surface, attack vector, security requirements, least privilege, immutability, compliance, and so on. Secondly, the identity and access management section covers the key topics in the IAM, such as identity, user identity, service identity, secrets, credentials, certificates, and so on. The third section covers the hardware devices that are designed to enable security functionality, such as Trusted Platform Module, Virtual Trusted Platform Module, Hardware Security Module, Root of Trust, Hardware Root of Trust, and so on. And finally, the tooling section covers the security tests and assessments, such as vulnerability scanning, container image scanning, static analysis, dynamic analysis, and so on and so forth. It's natural that a process, policy, or a documentation is not something everybody would like, but we all agree that it's very important to govern our day-to-day activities. So in this section, I would like to give a quick walkthrough of one of the section I have defined earlier. So I wouldn't like to dive deep into each of the definitions. However, I just want to touch upon a few from this identity and access management, which was the main driver to initiate this project. There has been a lot of back and forth discussions on what identity actually was in theory and in reality, and how the definition needed balance with the right correct recommendation or the best practices and not necessarily how it was implemented. With this, let's start with identity. Identity is any document, file, that serves to establish who or what the bearer is. An identity could be a person or a non-person entity. However, its ultimate purpose is to establish what it is representing. Further, a user identity is an identity that represents a person as a bearer. A person could be having multiple identities across multiple trust domains and systems, or they could have a single identity and it could be used as a federated one across domains and systems. Thirdly, the service identity on the other hand is an identity that is used to distinguish non-person entity. The core objective of the identity and access management section is to stop impersonation attacks by using strong authentication. Once the digital identity has been established and attested, it must be maintained, modified, and monitored throughout each user's access lifecycle. The overarching goal of the identity management is itself to establish and verify identity granted to intended persons, hosts, and services in order to successfully facilitate authentication and authorization of the identities to protect assets. The last definition I would be touching upon today is secrets, which is an object that contains sensitive data, such as password, token, or a private key. Users can create these secrets as well as the system can also create these secrets. This is not the end. As mentioned earlier, we have a bunch of terminologies defined and standardized for the cloud native security. Do check the project out. And finally, we intend to keep the lexicon relevant and expand it to include other relevant terminologies, definitions, and add new definitions as and when required. And your support is of utmost importance. If you'd like to contribute on expanding the lexicon to include other frequently used terminologies, use cases, or even anything that you think would be relevant for the cloud native security lexicon, do join our Slack channel and open a PR and get the conversation rolling. Let us together make this a single source of reference for the security terminologies in the cloud native landscape and include it in each and every ongoing and budding projects in the CNCF. Our Slack channel and GitHub channels are mentioned here. So please feel free to ping us and open a PR and let's get the conversation rolling. Finally, here is a shout out to all the wonderful folks who have made this project possible. Thank you so much.